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PREFACE 


This manual describes the concepts necessary to use _ the 


Perkin-Elmer OS/32 Basic Data Communications software. Included 
in this manual is a description of the areas of application, 
program interface, 0S/32 support features and internal 
operations. 


Chapter 1 introduces basic data communications facilities. 
Chapter 2 introduces the 0OS/32 Basic Data Communications 
Subsystem. The differences between device-independent and 
device-dependent. access are detailed and brief descriptions of 
Perkin-Elmer adapters, line drivers and terminal managers are 
included. Chapter 3 describes device handling through supervisor 
call 7 (SVC7) or the OS/32 command language. The SVC7 parameter 
block and related functions are discussed as well as the 0S/32 
commands pertinent to data communications. Chapter 4 discusses 
device-independent access of data communications facilities, 
which is accomplished by using the SVCl parameter block described 
in this’ chapter. Chapter 5 details device-dependent access of 
data communications facilities through the use of line drivers, 
which is accomplished by using the SVC15 parameter block 
described in this chapter. SVC15 buffer types and the driver 
command word (DCW) are also detailed in Chapter 5. Chapter 6 
describes the various structures and routines used in the 0S/32 
Data Communicat.ions Subsystem. Chapters 7, 8 and 9 describe the 
internal operation of basic data communications and discuss’ the 
process of modifying or adding a line driver or terminal manager. 
These three chapters should be read by users whose requirements 
are not satisfied by basic data communications support. 


Throughout this manual, there are numerous’ references to the 
Integrated Telecommunications Access Method (ITAM). Prior to the 
RO5.1 version of OS/32, all Perkin-Elmer data communications 
software was packaged separately and was referred to as ITAM. 


This manual is intended for use with the 0S/32 R07.2 software 
release and higher. 


For information on the contents of all Perkin-Elmer 32-bit 
manuals, see the 32-Bit Systems User Documentation Summary. 
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CHAPTER 1 
BASIC DATA COMMUNICATIONS 


1.1 INTRODUCTION 


Put simply, the purpose of data communications is to transfer 
information. In the context of data processing, data 
communications refers to the exchange of information between 
computers or peripherals. 


All transmissions between locations require three things: 


@e a transmitter or message source, 
e a transmission medium, and 


@e a receiver. 


A simple telephone call is a good example of a data transmission. 
You, the caller, use a transmitting medium, the telephone and the 
telephone lines, to transfer information to the person you are 
calling. The same is true of a digital data communications 
network with one small addition. In a digital data 
communications system, the transmitter must not only be able to 
transmit the data, it must also be able to translate the source 
message from its original form into a form that can travel over 
the available transmission path. The receiver must then be able 
to translate the transmitted message back into a form that can be 
understood by people or machines. An analogy can be made with an 
earlier data communications system, the telegraph. Using a 
telegraph, the words of a message could not be sent directly, but 
had to be encoded into a system of dots and dashes that could be 
transmitted over a wire. The dots and dashes received would then 
have to be decoded into a language that the people receiving the 
message could understand. 


During the first half of this century, most of data 
communications involved voice transmissions. With the advent and 
increased use of digital computers, the importance of digital 
communications quickly became evident. Many users wanted their 
computer to be able to communicate with their customer's computer 
across town, or with another company's computer across the 
nation. Initially, this was not possible, because most 
conventional telecommunications facilities were developed before 
the birth of the computer and were, therefore, for voice rather 
than digital communications. 
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These analog (voice) systems were not fast enough to keep up with 
the speeds computers were becoming capable of. In addition, the 
earlier computers were not designed to be connected to an 
existing communications network. With the increasing demand for 
long distance computer communications, the field of digital data 
communications became an important part of the computer industry. 


1.2 DATA COMMUNICATIONS NETWORKS 


Data processing facilities are frequently joined together to form 


Gata communications networks. Such networks connect remote 
terminals and computer systems to each other and/or to a host 
computer. The earlier systems were connected via public 


telephone and telegraph lines, but large private networks using 
high-speed digital facilities and leased transmission lines soon 
evolved. Data can also be transferred by radio signals and, with 
the increased use of microwaves and the advent of space travel, 
by microwave relays to satellites. 


If a single transmitting device is connected to a single 
receiving device, the data communications network is considered 
to have a point-to-point line (see Section A of Figure 1-1). To 
decrease the costs of such a network, more than one terminal can 
be connected over a single dedicated line. This type of line is 
referred to as a multidrop (or multipoint) Line (see Section B of 
Figure I=L). When using a multidrop line, the processor 
communicates with a terminal by one of two methods: 

@ polling and selection, or 


® collision avoidance/collision detection. 
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Figure 1-1 Point-to-Point and Multidrop Networks 
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Polling is the process by which the computer queries each 
individual terminal to see whether or not that terminal has any 
data to transfer. The processor accomplishes this by sending out 
a unique bit sequence (ID) that can be recognized by a particular 
terminal as its address. The terminal then responds either 
positively or negatively. A negative response causes the 
processor to query the next terminal. A positive response causes 
the processor to take the necessary steps for a data transfer to 
occur. Polling is useful in large networks where tight control 
over line usage is desired; it is also applicable in cost- 
conscious facilities or in applications where transmitted 
messages have different levels of priority. 


Selection is the mechanism by which the _ processor itself 
specifies the terminal to which it wants to transmit data. This 
is accomplished by using the terminal's ID. Multidrop networks 


are able to broadcast a message to all of the terminals on the 
multidrop line. 


In collision avoidance/collision detection, a terminal first 
"listens" to see if another terminal is sending data. Only if no 
other terminal is transmitting will it attempt to send data. If 
more than one terminal happens to start transmitting at the same 
time, both cease transmissions and wait a specified and different 
amount of time before they attempt to transmit again. The 
advantage of this method is that the processor is not needed to 
control the actual process as in the polling method. The main 
disadvantage is that there is no limit on the amount of time a 
low-priority terminal might have to wait before transmitting. 


A special type of data communications network is the distributed 
processing network. Such networks divide the data processing 
among several smaller computers. This arrangement improves’ the 
overall performance of the network, since a failure at one node 
does not affect the other processors and peripherals. Such an 
arrangement also provides increased reliability because 
distributed networks provide alternate paths to other processors 
in the event of a nodal failure. 


1.3 A BASIC DATA COMMUNICATIONS SYSTEM 


Figure 1-2 depicts a simplistic data communications network. 
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Figure 1-2 A Simplistic Data Communications Network 
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The components of the system in Figure 1-2 are numbered and 
represent the hardware usually needed in any data communications 
system. These devices are the: 


1. Terminal 

2. Modems 

3. Transmission lines 

4. Multiplexors and concentrators 

5. OS/32 Data Communications Subsystem 


6. Processor 


Components 1 through 4 and 6 are not actually part of the 0S/32 
Data Communications Subsystem. They are, however, essential to 
the operation of a data communications system. The remainder of 
this chapter is, therefore, dedicated to a general discussion of 
these components so that a better understanding of their 
functions in a data communications system can be achieved. This 
discussion is intended for the reader who does not have an 
extensive background in data communications. The more 
experienced reader may skip this discussion. Chapter 2 contains 
a detailed discussion of the 0S/32 Data Communications Subsystem. 


1.3.1 Terminals 


Communication between people and computers generally requires a 
terminal with a keyboard and some type of display device. 
Clearly, the CRT terminal provides the fastest and the most 
convenient access to the data stored or manipulated by a 
computer. While the CRT is the most popular type of data 
communications terminal, the characteristics of the many CRTs 
currently manufactured vary a great deal. In general, data 
communications terminals can be classified according to their 
communications mode, data transmission speed, data transfer mode 
and data code format. Sections 1.3.1.1 through 1.3.1.4 discuss 
these classifications. 


1.3.1.1 Terminal Communications Modes 

Data communications terminals can be divided into three modes’ of 
operation: 

e Simplex 

e Half-duplex 


@e Full-duplex 
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Figure 1-3 depicts these three modes. 
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Figure 1-3 Terminal Communications Modes 


A simplex terminal uses a simple l-wire link with its receiving 
counterpart. Im other words, a simplex terminal has a one-way 
only transmission path. Data cannot reverse directions. 


A half-duplex terminal is a 2- or 4-wire terminal link that 
allows two-way communications, but transmissions can only occur 
in one direction at a time. The installation of special 
equipment that reverses the receive or transmit condition is 
required. Half-duplex terminals are often connected to 4-wire 
links to avoid turnaround delays (i.e., the modem switching 
itself from transmitting to receiving mode and vice-versa. ) 


In a full-duplex mode, the terminal is connected via a 4-wire 


link, which allows two-way simultaneous transmissions. Data can 
be sent and received at the same time. 
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An analogy can be made between these terminal modes and city 
streets. A simplex line is analogous to a one-way street in that 
traffic can only travel in one direction. The half-duplex mode 
is similiar to a narrow two-way street; traffic can travel in 
both directions, but only in one direction at a time. 
Full-duplex mode is the same as a standard two-way street; 
traffic can travel in both directions simultaneously. 


1.3.1.2 Terminal Speeds 


Although it is being replaced as a unit for measuring signaling 
speed, the baud is the basis of all other units of signaling 
speed. A baud is defined as the number of signal events per 
second. This definition is the basis for the two main units of 
signaling speed in use _ today: bits per second (bps) and 
characters per second (cps). If each bit transferred represents 
one signal event, the speed is expressed in bps. If a character 
represents one signal event, then the speed is expressed in cps. 


Data terminals are divided into three basic speed catagories. 


e Standard - up to 30cps 
@ Medium - 30 to 480cps 


e High - over 480cps 


1.3.1.3 Data Transmission Modes 


Data can be transmitted using one of two possible modes: 
asynchronous: or synchronous. Most low- and medium-speed 
terminals transmit data in the asynchronous mode. These 
terminals generate a coded character each time a key is 
depressed. Figure 1-4 illustrates the asynchronous’ transmission 
mode. 
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Figure 1-4 Asynchronous Transmission 
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In asynchronous transmission mode, each character is prefixed by 


a start bit and suffixed by one or more stop bits. In this mode, 
the performance of one operation is initiated by the signals that 
indicate the completion of the previous operation. In other 


words, a new character cannot be transmitted until the previous 
characters have been received. All bits within a character: are 
sent at prescribed time intervals, but the data can have periods 
of inactivity while the terminal is waiting for the operator to 
input more data. In the asynchronous mode, the timing of the 
terminal and the central system are established independently of 
each other. 


Most high-speed terminals transmit their data in the synchronous 
mode. In synchronous transmissions, the data is transmitted in 
long blocks with only a single framing pattern at the beginning 
of each block. These framing characters are referred to as 
‘sync' characters. The advantage of this mode of transmission is 
that each character transmitted consists only of data bits. 
Transmission facilities, therefore, are used more efficiently 
because there are no signal elements being wasted as start and 
stop bits. Figure 1-5 illustrates the synchronous transmission 
mode. 
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Figure 1-5 Synchronous Transmission 


Unlike the asynchronous transmission mode, timing in the 
synchronous mode _ is established and maintained by the 
transmitting and receiving modems. These devices are 
synchronized so that transmissions occur at a fixed rate. No 
gaps are permitted between characters in the data block. 
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1.3.1.4 Data Codes 


Data is represented in a computer by a collection or series of 
binary digits arranged in a particular order or grouping. These 
groupings are known as data codes and the three basic data codes 
used for data communications are Baudot, ASCII and EBCDIC. 


e The Baudot code is a 5-bit code which makes only 32 unique 
characters possible. Because of this, two of the characters 
must be used as shift characters so that the code can handle 
the variety of letters, numbers and special characters 
necessary. The Baudot code has no provision for error 
checking. Terminal control is acheived by a line break or a 
special character sequence. Baudot was used principally on 
early teletype (TTY) machines; it is not in much use today. 


@e ASCII (American Standard Code for Information Interchange) is 
a 7-bit code with an additional bit to check for parity. It 
has unique code assignments for both alphanumeric and control 
functions. ASCII is the most widely used code today and is 
found on most micro and minicomputers. All Perkin-Elmer 
computers use the ASCII data code. 


@ EBCDIC (Extended Binary Coded Decimal Interchange Code) is an 
8-bit code similiar to, but not compatible with, ASCII. It 
also uses a parity bit to check for. errors. EBCDIC was 
created by IBM®for use on their large computer systems. 


In parity checking, the processor verifies that all characters 
have either an even number (even parity) or an odd number (odd 
parity) of bits. After the transmission is completed, the 
receiving computer checks’ the parity to verify that all of the 
data has been transferred completely. If all of the characters 
do not have the correct number of odd or even bits, the computer 
notifies the transmitter that an error has occurred in 
transmission. 


It is essential that all components of a data communications 
system can “converse” with each other in the same data code. If 
this is not the case, none of the data transferred will make 
sense to the receiving station. The solution is an emulator, a 
device or piece of software that makes a computer system 
supporting one data code behave like another system supporting a 
different code. Using emulators, it is possible for an ASCII 
terminal to "converse" with an EBCDIC processor. 
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IBM® is a registered trademark of International Business Machines 
Corporation. 
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1.3.2 Modems 


Even though there are many other media available, the voice 
frequency channel or phone line is still the most popular medium 
for transmitting data because of its high availability and low 
cost. When using phone lines, a device known as a modem 
(modulator/demodulator) is required to interface between the 
processor or terminal and the communications line. The function 
of a modem (sometimes called a "data set") is to facilitate 
digital data communications over a telephone network by 
converting the digital (square wave) signal to an analog (sine 
wave) signal. It is this analog or "voice" signal that can be 
transmitted over the phone lines. At the other end of the _ line 
is a second modem that demodulates the analog signals back into 
digital signals. In our example of the telegraph, the modem is 
analogous to the telegraph operator who codes and decodes the 
telegrams. The modem can actually be a part of the computer or 
terminal (integrated) or it can be a stand-alone model. Modems 
can be divided into three types: 


@e Voice grade 
@e Wideband 


e Hard-wired 


Voice grade modems can be further divided into two speed 


catagories: low and medium. Low-speeqd modems are used on 
switched networks and interface with low-speed asynchronous 
terminals. These modem types generally operate at speeds of up 
to 300bps. Medium-speed modems are used with terminal 


controllers and high-speed terminals and can operate at speeds of 
9,600bps and higher. 


Wideband modems have very high operating speeds of 19,200 to 
460, 800bps. They are interfaced with special wideband leased 
lines and are used primarily for processor-to-processor 
transmissions. 


Hard-wired modems operate on dedicated lines at speeds of up to 
one million bits per _ second. These modems are generally 
limited-distance devices that are very useful for short distance 
data communications. 


Modems are not required when short distance direct lines can be 
used. Only when the transmission is to take place over telephone 
lines is a modem needed. 


Another function of a modem is referred to as_ handshaking. 
Handshaking is the procedure that occurs when two modems are 
connected for the first time; it ensures that the communications 
link is available and functional. This is accomplished through 
the use of control signals sent down the line and returned. A 
handshaking sequence is unique to the particular type of modem. 
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Modems must operate in the same modes as the terminals to which 
they are connected. A half-duplex modem sends or receives data 
in only one direction at a time while a full-duplex modem can 
send and receive information concurrently. Each modem can 
transmit or receive either asynchronous or synchronous data. 
1.3.3 Transmission Lines 

Transmission lines are classified as one of three types according 
to the speed of transmission. The transmission types are: 

e Low-speed (subvoice) 

@ Medium-speed (voice-grade) 

e High-speed (wideband) 


Low-speed lines are commonly used by Telex, TWX and other TTY 
transmissions. Both leased and switched networks can be used and 


can transmit data at up to 300bps. Telex and TWX are used 
primarily for transmitting business communications. Connections 
are established by dialing into these networks, but 


intercommunication is made via TTY rather than by voice. 


Medium-speed networks are made up of voice-grade telephone lines. 
These telephone lines can be grouped into three catagories. 


@e Switched, or public, lines make up the standard telephone 
system and provide a dial-up service between the terminal and 
the processor. Switched lines can transmit data 
asynchronously up to 1,200bps or synchronously at rates of up 
to 4,800bps. This type of connection is less costly if the 
line's usage is low and infrequent. 


@e Leased lines are private point-to-point lines that are 
dedicated to a particular customer. The advantages of this 
type of line are that the connection between points is 
constant; it does not have to be established each time and the 

private line allows the user more bandwidth. These advantages 
make higher data transmission rates possible and make this 
type of connection less costly if the line is to be used 
frequently or constantly. 


In contrast to switched lines, leased lines can transfer data 
up to twice as fast and can achieve a speed up to 9,600bps. 


@ Special lines are 4-wire links that are available for two-way 
transmissions. These links usually have a higher speed and a 
lower error rate than switched lines, due to _ conditioning. 
Conditioning refers to the process of adjusting the electrical 
characteristics of the transmission path to control certain 
types and levels of distortion. 
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High-speed or wideband lines have transmission rates of 19,200bps 
or more. They are used primarily for intercomputer communication 
links. 


1.3.4 Multiplexors (MUXs) and Concentrators 


MUXs and concentrators are data communications devices’ that 
improve system efficiency by increasing the speeds of data 
transmissions. 


A MUX is a device that receives and combines signals from many 
low-speed lines and transmits them together over the same 
high-speed communications channel. 


A concentrator is a device that is used to interface many 
different terminals to a_ single host computer. Like a MUX, a 
concentrator combines the many low-speed lines into a_e single 
high-speed line. 


In using data multiplexing, the instantaneous rate of data 
entering or exiting the terminal cannot exceed the data rate of 
the communications channel. A concentrator, however, uses a 
buffered resource sharing scheme so the instantaneous rate of 
data entering or exiting the terminal can exceed the data rate of 
the communications channel. Data concentration can, therefore, 
take advantage of idle terminal time, while data multiplexing 
cannot. 
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CHAPTER 2 
OS/32 DATA COMMUNICATIONS SUBSYSTEM 


2.1 INTRODUCTION 


One of the most important components of any data communications 
system is the interface between the communications lines and the 
processor. This interface must be able to transform the signal 
levels and data rates produced in the communications circuit into 
levels and rates that the processor can understand. This is done 
with a unique combination of hardware and software that makes up 
the Perkin-Elmer OS/32 Data Communications Subsystem. Figure 2-1 
shows the general breakdown of the subsystem. 


Sections 2.2 through 2.5 discuss the components of the subsystem. 
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Figure 2-1 A Data Communications Subsystem 
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Perkin-Elmer supports two basic network types: 


@e PENnet is a distributed data communications network for long 


distance digital transmissions. It uses either leased or 
switched phone lines and cyclic redundancy checking (CRC) for 
error detection. PENnet is easy to install and use since no 


specialized knowledge of data communications networks is 
required to exploit its full facilities. 


e Ethernet is a local area network (LAN) that uses a 
peer-to-peer protocol known as carrier-sense multiple access 
with collision detection (CSMA/CD). Components of an Ethernet 
network are connected by coaxial cable over a limited distance 
of about 1.5 miles with the use of repeater stations. This 
system transmits data at a rate of lOMbits per second. For 
further information see the 0S/32 Network Drivers Programming 
Reference Manual. 


2.2 ADAPTERS 


Communication adapters are hardware boards that interface the 
processor with a transmission facility and enable remote devices 
to communicate with the host computer. In general, an adapter 
contains circuits to generate and detect the control signals 
required to set up, take down and supervise the data 
communications channel and to provide proper status and interrupt 
information to the processor. There are two basic types of 
adapters: serial and parallel. Serial adapters interface with 
modems and usually use the Electrical Industries Association 
(EIA) RS-232 standard signals. Parallel adapters can _ connect 
indirectly to the computer's input/output (I/0) channels. 


Perkin-Elmer's OS/32 Data Communications Subsystem supports three 
basic types of serial adapters: 

@® asynchronous 

e bisynchronous 


@® zero-bit insertion and deletion (ZBID) 


2.2.1 Asynchronous Adapters 


In the asynchronous mode, Gata is transferred 
character-by-character. Each character is preceded by a start 
bit and is followed by one or two stop bits. The disadvantage of 
this type of transmission is that a substantial percentage of the 
bits transmitted are used simply for separating characters; thus, 
this method of transmission is more costly since the 
transmissions are longer. 
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The Perkin-Elmer OS/32 Data Communications Subsystem supports the 
following asynchronous adapters: 


e The programmable asynchronous single line adapter (PASLA) 
provides an interface between 103/202-type modems over either 
a switched or leased network. It can accommodate local 
terminals that match the EIA RS-232 standard. This system has 
a high degree of flexibility in that it can be programmed for 
a variety of baud rates, character formats and line control 
functions. PASLA can also interface with either a half-duplex 
or fulli-duplex line. The major disadvantage is that each 
device must have its own PASLA. 


@e The 2-line MUX is a halfboard that is equivalent to two 
PASLAs. 


e The 8-line MUX is a fullboard that is equivalent to eight 
PASLAS. 


e The multiperipheral controller (MPC) contains the 8-channel 
data communications multiplexor (COMM MUX) consisting of four 
serial communication controllers. Each controller contains 
two independent, full-duplex channels that can be 
asynchronous, bisynchronous or ZBID interfaces, depending on 
the needs of the user. 


2.2.2 Bisynchronous Adapters 


Bisynchronous (binary synchronous or BISYNC) adapters use _ the 
BISYNC mode of data transmission. In bisynchronous 
communications, data is transmitted in a synchronous mode _ with 
special communications control] characters that are specified for 
formatting text, indicating status, synchronizing functions and 
error control. 


The OS/32 Data Communications Subsystem supports the following 
bisynchronous adapters: 


e The synchronous 201 data set adapter contains the circuits 
necessary to generate and detect control signals that are 
needed to establish, maintain and terminate the data 
communications channel and provide status and interrupt 
information to the computer. The data transfer between a 201 
modem and a 201 data set adapter occurs in the bit serial mode 
with a synchronizing bit clock supplied by the modem for both 
transmitting and receiving. Special character recognition 
(other than the SYNC characters), block character checking and 
generation, and code translation are accomplished by the 
processor under program control. 
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e The quad-synchronous adapter (QSA) is designed to operate with 
synchronous modems and provides an interface between a 
selector channel (SELCH) bus and four 2-wire or 4-wire 
synchronous modems. Like the 201 data set adapter, data 
transfer between the QSA and a modem is in the bit serial mode 
with a bit clock supplied by the data set. The QSA also has 
the logic necessary to generate and detect control signals 
which are needed to establish, maintain and terminate a data 
communications channel, and provide proper status and 
interrupt information to the processor. 


e The single-synchronous adapter (SSA) is a synchronous’ adapter 
that, like the 201 and the QSA adapters, contains the logic 
necessary to generate and read the control characters which 
are needed to set up, supervise and terminate a data 
communications channel, and provide the proper status and 
interrupt information to the processor. 


@e The MPC can be used as a bisynchronous adapter as well as an 
asynchronous adapter. See Section 2.2.1 for further details. 


2.2.3 Zero-Bit Insertion/Deletion (ZBID) Adapters 


ZBID adapters are synchronous’) adapters different from BISYNC 
adapters. ZBID devices send data in frames, each of which starts 
and ends with a particular bit sequence called a flag. ZBID gets 
its name from the need to prevent the data being transmitted from 
resembling the ZBID flag sequence. To accomplish this, the 
sending station inserts a zero bit, whenever necessary, to 
prevent the data from appearing as a flag sequence. These zero 
bits are removed by the receiving station. Hence its name, zero 
bit insertion and deletion. ZBID is synonymous with synchronous 
data set link control (SDLC) transmission modes. 


The OS/32 Data Communications Subsystem supports the following 
ZBID adapters. 


e@ QSA 
e SSA 
@e MPC 
The Ethernet data Link controller (EDLC ) provides 
processor-to-processor serial communications at a rate of lOMbits 
per second over a common coaxial cable. Communication sequences 


over the half-duplex channel are divided into packets with frame 
sizes ranging from 64 to 1,518 bytes. Each frame has two 48-bit 
address fields, one 16-bit type field and a 32-bit cyclic 
redundancy check (CRC) frame check sequence for error detection. 


The QSA, SSA and MPC support ZBID devices as well as 
bisynchronous devices. See Section 2.2.2 for further details. 
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2.3 LINE DRIVERS 


A line driver provides a standard software interface between the 
particular communications adapter and the user task (u-task) or 
special support programs in the processor. In general, a_ line 
driver allows the user to specify the control sequence and. the 
data necessary to send or receive a transmission over a data 
communications line. More specifically, a line driver: 


e interfaces with the communications hardware (adapter), 

e controls reads and writes to or from the communications lines, 
e performs certain basic timing functions, and 

e controls some modem signals. 

A line driver is essentially “dumb"; it does not know what is at 
the end of the communications line with which it is interfaced. 
The line driver, however, does know how to control the adapter in 
order to pass data to or from the communications line. The 
protocols and procedures necessary to initiate, maintain and 
terminate the communications link must be supplied by either 
special support software or the u-task with which the driver is 
interfaced. 

The OS/32 Data Communications Subsystem supports four line 


aQrivers. 


e DASY is an asynchronous line driver that interfaces with 0S/32 
asynchronous adapters (e.g., PASLA). 


e DCSY is a character synchronous line driver that interfaces 
with bisynchronous adapters (e.g., Q/A). 


e DZBD is a ZBID line driver that interfaces with ZBID adapters 
(e.9., MPC). DZBD controls line synchronization, data 
transparency and data blocking for medium- to high-speed 
(1,200 to 19,200 baud) communications lines. 

e DETH is the Ethernet line driver, which is a ZBID line driver 
that interfaces with the EDLC. 

2.4 DEVICE-INDEPENDENT ACCESS 

The OS/32 Data Communications Subsystem supports two levels of 

data communications access: 


@ Device-independent 


e Device-dependent 
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Device-dependent access is discussed briefly in Section 2.5 and 
more fully in Chapter 5. 


The device-independent access level is ideal for the 
noncommunications-oriented user because it allows the user to 
extend the range of the system beyond the computer room. 
Device-independent access permits the user to communicate with 
remote terminals over communications lines with normal 0S/32 
supervisor call 1 (SVC1l) I/O conventions just as if the data 
communications terminals were local peripherals. 
Device-independent access is discussed more fully in Chapter 4. 


2.4.1 Terminal Managers 


Device-independent support of communications devices is provided 


by OS/32 terminal managers. In data communications, a logical 
device, such as a CRT, processor or printer connected over some 
type of communications line, is Known as aterminal. A data 


communications terminal needs a coordination protocol and certain 
buffer management procedures in order to be supported over a 
particular type of communications facility. Data communications 
terminals can be treated as local devices since the details of 
hardware requirements are handled by terminal managers. 


A terminal manager is actually software support that contains the 
logic to initiate, maintain and terminate transmissions to a data 
communications terminal. The user accesses the terminal manager 
through SVCl. The terminal manager, in turn, calls a line driver 
and, using the line driver features, supports the terminal ina 
device-independent manner. The concept of a communications 
device with device-independent access by a terminal manager is 
analogous to the concept of a direct access file with file 
manager support. The user program presents data to or requests 
Gata from the terminal just as it would for any local device or 
file. The terminal manager performs the necessary physical I/O, 
communications line handshaking and/or data formatting. 


The 0S/32 Basic Data Communications Subsystem supports four 
different terminal managers; they are depicted in Figure 2-2. 
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Figure 2-2 0OS/32 Terminal Managers 
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e MASY is an unbuffered terminal manager that interfaces the 
DASY driver with “dumb" terminals or printers (device codes 
147). See the 0OS/32 System Generation (Sysgen) Reference 
Manual for further information on device codes. MASY works in 
a conversational mode only and performs some very basic 
formatting functions (e.g., carriage returns (CRs), line feeds 
and trailing space truncations). 


e MBSC is a buffered terminal manager that interfaces with the 
DCSY line driver and intelligent terminals. MBSC works with 
binary synchronous transmissions using the 2780 or 3780 
protocols. 


@e PPSM is a nonbuffered terminal manager that interfaces between 
DASY and intelligent terminals in a point-to-point 
environment. It is used with devices having device codes 156 
and 157. PPSM supports conversational data modes, as does 
MASY, but PPSM also supports a block transmission mode. This 
driver is used by OS/32 Reliance. 


e@e MMSM is a nonbuffered terminal manager that interfaces between 
DASY and intelligent terminals in a multidrop environment. It 
is used with devices having the device code 158. MMSM has the 
same block support as PPSM, but is used for a multidrop 
environment (i.e., many terminals connected to a single data 
communications line). 


Both PPSM and MMSM use an additional software module. known as 
MSUP . MSUP contains code that is used by both PPSM and MMSM in 
conjunction with their own differing software. MSUP's use is 
analogous to two user tasks, both different, but both needing to 
access the same library subroutine. Because of this, PPSM and 
MMSM could be more correctly called PPSM-MSUP and MMSM-MSUP. 


2.4.2 Protocols 


A protocol is a set of conventions for the establishment and 
maintenance of a data transmission line. In other words, a 
protocol is a set of rules that the computer and/or terminal 
follow when using data communications facilities. Military radio 
communications are a good example of communications protocol. A 
communications link is requested with "This is XYZ calling ABC." 
Acknowledgments are made with a "Roger" and the end of a 
transmission is signified by an "Over". These particular 
responses are a part of the established protocol of military 
communications. A data communications protocol is similiar, but 
much more regimented. In a data communications protocol, the 
conventions are precise and must be followed exactly. 


Data communications protocols provide facilities for error 


handling, handshaking, coordination procedures for switched 
networks and failure recovery. 
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Error handling includes both error detection and error correction 
techniques. Error detection is based on redundant information in 
the transmitted message. Correction of detected errors is 
generally done by retransmission of a portion of the message as 
provided for in the protocol. Another method of error correction 
is the replacement of an error with a special character. for 
manual error correction. 


Character errors can be checked by a method known as vertical 
redundancy checking (VRC). In this technique, a parity bit is 
added to the character bits and the process checks for either odd 
or even parity. If a character with the incorrect parity is 
detected, it is treated as an error. 


The disadvantage of VRC is that it can only detect a single or an 
odd number of bit errors. Another technique of error checking is 
needed to find multiple errors. One such technique is to place 
parity bits along a data block in addition to those used by VRC. 
These special bits are added at the end of the block so the bit 
parity is always odd. This technique is referred to as 
longitudinal redundancy checking (LRC). LRC is computed by 
taking the exclusive-OR of a zero character successively with 
each character in the block. 


CRC is another, more powerful way of detecting errors. This 
method is essentially a combination of VRC and LRC. In CRC, a 
polynomial formula is used to generate a special checking 
sequence at both ends of the transmission network. The result of 
this sequence is sent by the transmitting station to the 
receiving station and is compared to the value of the sequence 
calculated by the receiving station. If the two values are not 
equal, errors have occurred. CRC is capable of detecting 
multiple bit errors and many burst-type errors. 


A protocol known as the data link control protocol defines’ the 
general control framework for the data communications network. 
A terminal can have its own internal protocol, different from the 
general control protocol. However, some type of control over 
terminals is necessary in multiterminal networks where there are 
many terminals connected to a single _ line. The process of 
polling terminals uses a protocol to request and establish 
communications links between the processor and a terminal 
requesting the link. 


Another type of protocol is known as a communications protocol. 
This protocol provides rules for transmission and reception of 
the different types of data streams. For example, the advanced 
data communications control procedure (ADCCP) is a synchronous, 
bit-oriented, code-independent, interactive protocol specifically 


designed for computer-based data communications over a 
full-duplex mode. Other communications protocols are designed to 
be character-oriented, or for asynchronous’ transmissions, 


or to be used over a half-duplex transmission mode, etc. 
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For information on the protocols 


supported by the 0OS/32 Data 


Communications Subsystem, see the 0S/32 Asynchronous, 
Bisynchronous, Bit-Synchronous and Network Drivers Programming 
Reference Manuals. 

2.5 DEVICE-DEPENDENT ACCESS 

Device-dependent support of communications devices is often 
referred to as the line driver access method because the user 


makes use of line driver 
parameter block. 


tailor a communications 


position of the line drivers in the 


Subsystem makes it easy 


control sequences needed to complete a_ transmission. 


level of support, the 
communications line by the 
this system allows 


communications system and 
buffer management and task 


The disadvantage of device- 


OS/32 terminal managers, 
communications control 
block. 
access be used. 


features 
Direct use of data communications line drivers 
provides the more primitive 


directly through the SVC15 

functions that enable a user to 
system to a particular need. The 
O0S/32 Data Communications 
user to specify the special 

For this 
assigned a 
The flexibility of 
tailoring of the 

command chaining, 


for the 
u-task need 
operating system. 
straightforward 
such features as 
interrupts (traps). 


only be 


dependent access, as opposed to the 


is that the u-task must specify all data 
sequences 
It is recommended that, when possible, device-independent 


through the SVC15 parameter 
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CHAPTER 3 
DEVICE HANDLING 


3.1 INTRODUCTION 


Data communications lines and/or terminals must be assigned or 
closed just like other devices. Also, line control blocks (LCBs) 
for OS/32 Data Communications buffered terminal managers need to 
be allocated and deleted just like direct access files. These 
allocations, assignments, etc., can be accomplished by using 
either the supervisor call 7 (SVC7) parameter block or the 
specific OS/32 operator commands. 


The SVC7 parameter block is covered in Sections 3.2 and 3.3. The 

use of system operator commands is discussed in Section 3.4. 

3.2 SUPERVISOR CALL 7 (SVC7) 

SVC7 is used in data communications to: 

@ allocate and delete LCBs for buffered terminal manager access 
(SVC1), 


@e assign and close logical units for line driver (SVC15) and 
terminal manager (SVC1l) access, 


e checkpoint buffered terminal manager access (SVC1), 


@® rename and reprotect data communications lines (SVC15 access 
devices) and terminals (SVCl access devices), and 


@e allocate and delete drop control tables (DCTs) for channel 
terminal manager (SVC1l) access or multidrop lines. 


This discussion of SVC7 includes only information pertinent to 
data communications. For in-depth discussions of SVC7 support, 
see the 0S/32 Supervisor Call (SVC) Reference Manual. 


3.2.1 Supervisor Call 7 (SVC7) Parameter Block 
SVC7 provides device-handling functions supported by the data 


communications subsystem. These functions are accomplished 
through the SVC7 parameter block and coding shown in Figure 3-l. 
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10(0) |2(2) 13(3) | 
Function code | Error status | lu 
| (SVC7.OPT) |} (SVC7.STA) | (SVC7.LU) | 
sos Sec cain ang Rea eal eos cmos" es: cee Se ern “Se tne cia ees a Bee aus imo Gaps Ria ee Sasi “ete oom ne cis nis Ss sn“ Sas" sacs “owns a ce ct 'cne i ae | 
WAS, ee ee ee eee ee t 
14(4) 15(5) 16(6) 
| Write key Read key Logical record length 
| (SVC7.WKY) {| (SVC7.RKY) |} (SVC7.LRC) ! 
(epeeun acco emcee td on ci Ge Re on oe | 
18(8) | 
H Device mnemonic | 
(SVC7.VOL) 
eiaper ania acne nel age pa piste Axons Cen Gea | 
}12(C) 
| | 
| | 
oar aee Filename 0000 0 0 2 2 2 FRE 
1 16(10) (SVC7.FNM) 
{ ! 
| | 
\- Eg A era ee mE ee ee Ca a I gE SET ty a i pe OP ef pO Pee nn Ree ! 
120(14) }23(17) 
Extension Not used 
(SVC7 .EXT) H 
[Se ee Se eae ee er ea Se aaa eae eee 
124(18) 
File size 
(SVC7.SIZ) 

SVC 7,parblk 

ALIGN 4 

parblk DC X'function code' 

DS ue 

DB lu 

DB ‘write key' 

DB ‘read key' 

DC H'record length' 

DC C'4-character device mnemonic' 

DC C'8-character filename’ 

DB C'3-character extension’ 

DB Not used for data communications 

DC F'file size' 

Figure 3-1 SVC7 Parameter Block Format and Coding 
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3.2.1.1 Function Code Field 

The function code field is a 2-byte field that contains the 
hexadecimal number indicating the function to be performed. The 
format of the function code field is shown in Figure 3-2. 


\ 


Command byte Modifier byte 
ag i EN ae ee ae 
;AtAf}?C}ERi]ERiIC}D {x C f° # Access {Access | File 
i;Lb?};stH i nNniPjtLjtL tit K {privileges {method }; types |} 
Bits 

0 1 2 3 4 5 6 7 8 10 11 12 13 15 


Figure 3-2 SVC7 Function Code Field 


The SVC7 function code field is divided into two l-byte sections. 
The first byte is referred to as the command byte and the second 
as the modifier byte. 


The command byte, bits O through 7, requests one or more file 
management functions. If more than one command bit is set, the 
respective functions are processed sequentially, left to right. 
The modifier byte, bits 8 through 15, modifies commands specified 
in the command byte. 


The data communications function of each bit setting in the SVC7 
function code field is explained in Section 3.3. 


NOTE 


The modifier field is not used ona fetch 
attributes call. Instead, the device 
code is returned in this field. 


3.2.1.2 Error Status Field 


The error status field is a 1-byte field that receives 
appropriate error codes when an error occurs while executing 
SVC7. 


The interpretation of the error status field depends on the 
command specified in the call. It is compatible with nondata 
communications status returns (see the OS/32 System Level 
Programmer Reference Manual). A zero status always means the 
desired options were performed without error. Table 3-1 details 
the SVC7 error status field bit settings. 
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TABLE 3-1 SVC7 ERROR STATUS CODE BIT SETTINGS 


| BIT HEX | FUNCTION | MEAN ING 
{ SES STeTEeTe st SSS II SESE SEES SSS BSS SSS ES SG OE GS es i 
0 i; (00) } All | No error; the requested | 
{| functions are complete | 
heceretetaiaiateeateieeerete sa Sada i oad Cea aS OSE | 
1 | (O01) | A,O | Illegal function; illegal | 
| FT or AM modifier 
| eer nnn nn nn nnn nnn nnn nnn nn nnn nnn aa aan nnns | 
2 t (02) | All but | Logical unit (lu) error; | 
{| A,D { illegal lu | 
crete aici cinis is ec arg es ee gia inert a AE a | 
3 tf §=6.(03) i A,O,D | Device error; no such 
|} device in the system 
leerasea pinta mire ieiohenan em raerce ata simon aciaiess Sane ness = ea eenSe | 
{ 4 H (04) | A,O,N,D | Name error; mismatch on { 
| Filename.ext field (may 
i H | indicate failure to i 
| allocate LCB when 
| assigning for buffered 
| access) 
Ce a ae reg a le sas | 
5 tf =©(05) | A | Size error; erroneous 
{ H | LRECL or SIZE field H 
Serer aan iin si cen ge mga es ag sarc RSL | 
6 i (06) | O,D | Protect error; erroneous |} 
{| protection keys 
lee an VET AE Ss ENR EME GR a GRR RRR | 
7 | (07) | O,H,N, | Privilege error; unable 
|} P,D | to obtain requested 
| privilege 
(paaa aded sins 5p a Wei Ene ee oe ue gee Ae | 
H 8 H (08) | O | Buffer error; unable | 
| | to obtain requested 
| privilege | 
[ii Sessa aieuin ner em aon aa caneia an mae | 
9 i} (09) | All but | Assignment error; lu not | 
| A,D | assigned or attempted 
} to mix SVCl and SVC15 
| access to same device 
Lasers anti oe ace mere x a aa ies temeiareaeratee a | 
i 10 | (OA) | A,N,P,D | Type error; nondirect 
| access device or device | 
|} off-line | 
aoe cs las ces ven Sma Seimei“ sae iss eas Ses eval, a) sae il asc ied sc res Ben ek de eee t 
t ! 
f 11 | (OB) {| A,O,N,D {| File descriptor (fd) { 
} error; illegal syntax 
Ms See este a er ea) ea sc a, msm “as me pis“ Sn <td eis “ns “gaa a et eRe Bt AO eh ott ’ 
I | 
12 (80-FF ) 0;C;D;T Input/output (1/0) error; 


| interpreted as SVCl 
{ status byte 
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3.2.1.3 Logical Unit (lu) Field 


This l-byte field contains a hexadecimal number indicating the lu 
assigned to the data communications device for which the function 
is requested. This field is used for all SVC7 functions except 
allocate and delete. 


3.2.1.4 Read and Write Key Fields 


Protection keys for devices are specified in this  halfword. 
These keys are required for the allocate, assign, reprotect and 
delete functions. It is recommended that they be reset to zero. 


When executing the SVC7 fetch attributes function, the device 
attributes are stored in the write and read key fields of the 
parameter block. 


3.2.1.5 Logical Record Length Field 


The logical record length field is a 2-byte field containing a 
Gecimal number that indicates the physical record length when 
allocating the buffered logical terminal manager. 


When executing a fetch attributes function, this field receives 
a number indicating the physical record length of the device 
assigned to the lu. 


3.2.1.6 Device Mnemonic Field 

The device mnemonic field is a 4-byte field containing ASCII code 
that indicates the name of the data communications line to be 
used when the allocate, assign, delete and fetch attributes 
functions are executed. 

3.2.1.7 Filename Field 

The filename field is an 8-byte field containing ASCII code that 
indicates the buffered logical terminal described by the LCB that 
is being allocated or assigned. 

When executing a fetch attributes function, this field receives 
the filename from the data communications device currently 
assigned to the lu specified in the parameter block. 


3.2.1.8 Extension Field 


This 3-byte ASCII field is treated as an extension of the 
filename. 
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3.2.1.9 File Size Field 

This 4-byte field contains a hexadecimal number indicating the 

block size established when an LCB is allocated. 

3.3 COMMAND FUNCTIONS 

This section briefly describes the command functions of the 

function code field as they relate to data communications. For 

a more detailed explanation of these command functions, see the 

0S/32 Supervisor Call (SVC) Reference Manual. 

3.3.1 Allocate Function 

The allocate function reserves memory space for LCBs or DCTs’ for 

SVCl access. The space reserved must be less than the user's 

remaining allotment of system space. 

The required parameter block fields for this function are: 

e Bits O and 13 through 15 (file type) of the function code 
should be set (hex mask X'8007'). 

@e Write key field 

@ Read key field 

@e Logical record length field 

e Device mnemonic field 

@e Filename field 

e Extension field 

e File size field 

For multidrop lines, a DCT must be allocated for each drop 

assigned. 

3.3.2 Assign Function 

The assign function establishes a logical connection between a 

line or terminal and the task. This is accomplished through a 

specified lu for either SVCl or SVC15 access. For buffered 

terminal access, the device mnemonic, filename and extension 


fields specify the name of a logical terminal given to a 
previously allocated LCB. 
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The required parameter block fields for this function are: 


@ Bit 1 of the function code must be set; bits 8 through 10 
(access privilege), 11 and 12 (access method) and 13 through 
15 (file type) should be set as needed (hex mask X'4Onn'). 


e lu field 

e Write key field 

@ Read key field 

@ Device mnemonic field 
@e Filename field 


@e Extension field 


Assignments of the same device to multiple logical units are 
governed by the specified access privileges. Multiple 
assignments are valid as long as assignments specify the same 
access method. Assignments of a device for SVC15 access when it 
is already assigned for SVCl access, or vice versa, is illegal 
regardless of the specified access privileges. The only legal 
access privileges for SVC15 assignment are those specifying both 
read and write access (B 100 through B 111). 


3.3.3 Change Access Privileges Function 


This function changes the current access privileges of an 
assigned device to the access privileges specified in the 
parameter block. The new access privileges must be compatible 
with the existing ones; otherwise, the existing access privileges 
of the device remain unchanged and an error status is returned. 
If the device is assigned with read-only privileges, a write 
access privilege change is not allowed. See the O0S/32 Supervisor 
Call (SVC) Reference Manual for a table of allowable access 
privilege changes. 


Not all OS/32 terminal managers support change access privileges. 

See the appropriate terminal manager's manual _ for further 

information. 

The required parameter block fields for this function are: 

e Bit 2 of the function code must be set; bits 8 through 10 
should be set, as needed, to indicate the desired access 


privileges (hex mask X'20n0'). 


e lu field 
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If an error is encountered while processing this request, the 
device remains assigned with its original access privilege. A 
device assigned for SVC15 access can only request read/write. 
access. 


3.3.4 Close Function 


The close function breaks the logical connection between an lu 
and a data communications line and terminal by closing the 


currently assigned line. For logical units assigned for a 
buffered terminal (SVC1) write access, partially filled buffers 
are written to the line (i.e., checkpointed). If there are no 


other assignments’ to this device, the data terminal ready (DTR) 

signal to the modem is dropped, disconnecting a switched line. 

This occurs whether or not the device is system generated 

(sysgened) as a switched line. 

The required parameter block fields for this function are: 

e Bit 5 of the function code field must be set (hex mask 
X'0400'). 


e lu field 


3.3.5 Delete Function 

The delete function removes a currently unassigned LCB from 

memory. The required parameter block fields are: 

e Bit 6 of the function code field must be set (hex mask 
X'O200'). 

@ Write key field 

@ Read key field 

e@e Device mnemonic field 

e Filename field 

e Extension field 


If the logical terminal name matches the name in the LCB, the LCB 
is deleted. 
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3.3.6 Checkpoint Function 


The checkpoint. function ensures that terminal data buffered in 
memory is transmitted to the terminal. The required parameter 
block fields for this function are: 


@e Bit 7 of the function code must be set; bits 11 and 12. should 
be set, as needed, to specify the required access method (hex 
mask X'Olnn'). 


e lu field 


If the lu requested is not assigned, an error code of xX'81' is 
returned. 


3.3.7 Fetch Attributes Function 


For proper operation, some programs require knowledge of the 
physical attributes of the device associated with a given lu. 
The fetch attributes function accesses and sends this information 
to the SVC7 parameter block. These attributes include the device 
mnemonic, filename, extension and buffer size. Device codes’ are 
sent to the modifier byte of the function code field and device 
attributes are stored in the write and read key fields. The 
logical record length field receives a device physical record 
length. The field differences for the fetch attributes function 
are illustrated in the 0OS/32 Supervisor Call (SVC) Reference 
Manual. 


When executing this function, the modifier (device codes) field 
receives a hexadecimal number indicating the device type. The 
System Generation/32 (Sysgen/32) Reference Manual lists all 
device codes. 


The device attributes field receives a hexadecimal number 
indicating certain device attributes. All supported attributes 
and corresponding masks are listed in the OS/32 Supervisor Call 
(SVC) Reference Manual. The hex mask for this function is 
X'0000' (no command bits set). 


3.3.8 Vertical Forms Control (VFC) Function 


The VFC option turns the VFC function on or off for a particular 
device. To execute this function, only the first four bytes of 
the SVC7 parameter block are required. 


To use the VFC function, the command byte of the function code 
should be set to X'FF'. To turn on the VFC function for a 
particular device, set the modifier byte to X'20'. To turn the 
function off, set the modifier byte to X'21'. The error status 
and lu fields are the same for all SVC7 services. 
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VFC is supported by device codes 156 and 157 only. See the 
System Generation/32 (Sysgen/32) Reference Manual for further 
information. 


3.3.9 Rename Function 


The rename function changes the device mnemonic table (DMT) entry 
for the device. This routine also changes the LCB.NAME and 
LCB.EXT fields when it finds a buffered terminal. 


The rename function may not be supported for all data 
communications terminal managers. See the appropriate terminal 
manager's manual for further information. 


3.3.10 Reprotect Function 


When parameters are passed by the user, the reprotect function 
changes the read and the write keys. Also, if a device is 
buffered, REP.DCB gets the device control block (DCB) address 
from the LCB. 


3.4 OPERATOR COMMANDS 


Data communications SVC7 support can be invoked via the 0S/32 
System operator commands. A brief description of the commands 
pertinent to data communications is given in this’ section. See 
the OS/32 Operator Reference Manual for a detailed description of 
these commands. 


The term ITAM, which appears in the following commands, is 
synonomous with the term data communications. 
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3.4.1 ALLOCATE Command 
The ALLOCATE command is used to allocate an LCB for data 


communications buffered terminal access. 


Format: 


mcr co so ND SH) [Lee 


Parameters: 


fd is the file descriptor of the buffer or device 
to be allocated. 


ITAM specifies that the device to be allocated is 
a data communications device. 

lrecl is a decimal number specifying the logical 
record length of a data communications device. 
It cannot exceed 65,535 bytes. lrecl may 


optionally be followed by a slash (/), which 
delimits it from bsize. If no logical record 
length is specified, 80 is the default. 


bsize is a decimal number specifying the physical 
block size to be used for buffering and 
debuffering operations on the data 


communications device. 


When ITAM is specified, bsize represents’ the 
buffer size in bytes. For ITAM buffers, this 
parameter cannot exceed the maximum block size 
established by the sysgen procedure. If bsize 
is omitted, the default value for the ITAM 
buffer will be the "standard" buffer size for 
the particular device. 


keys specifies the write and read protection keys. 
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Functional Details: 


The fd must specify the device mnemonic for the desired data 
communications terminal, plus a unique filename and extension for 
each lu to which the terminal is to be assigned. If an LCB: for 
the specified filename and extension already exists, a NAME-ERR 
message is returned. 


The operator DISPLAY ITAMTERM command can be used to display 
allocated LCBs in a manner analogous to that of the DISPLAY FILES 
command. See the OS/32 Operator Reference Manual for a 
description of these commands. 
Examples: 
The following allocates an LCB for a binary synchronous’ terminal 
called RJE.IN on device BSCl1:. ; 

AL BSC1:RJE.IN, ITAM, 80/404 


The following allocates an LCB for a binary synchronous’ terminal 
called INPUT on device BSCl. Here the default logical record 
buffer and block size are used. 


ALLOCATE BSC1: INPUT, ITAM 
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3.4.2 ASSIGN Command 


The ASSIGN command assigns a data communications device to a 
task's logical units. 


Format: 
access privileges keys SV 
ASSIGN lu,fd|, ; ,) SVC15 
SRW 9000 ] SVCF 
| VFC 
Parameters: 
lu is a decimal number specifying the logical 
unit number to which a device or file is to be 
assigned. 
fa is the file descriptor of the device or file 
to be assigned. 
access specifies the desired access privileges. 


privileges Possible access privileges are: 


SRO Sharable read-only (SVCl access) 
ERO Exclusive read-only (SVCl access) 
SWO Sharable write-only (SVCl access) 
EWO Exclusive write-only (SVCl access) 
SRW Sharable read/write (default) 
SREW Sharable read, exclusive write 
ERSW Exclusive read, sharable write 
ERW Exclusive read/write 


NOTE 


The ASSIGN command is rejected if 
the specified access’ privileges 
cannot be granted. For SVC15 
access, the assignments must 
specify both read and write 
access. Assignment for SVC15 
access is rejected if read-only or 
write-only access is requested. 
Assignment for SVC15 access is 
also rejected if the device is 
already assigned for SVCl access, 
and vice versa. See the 0S/32 
Operator Reference Manual. 
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keys signify the write/read protection keys of the 
device to be assigned. 


SVCl signify which SVC parameter block is to be 
SVC15 used. SVC15 signifies that the specified 
SVCF device is to be assigned for SVC15 access. If 
VFC SVC15 access is specified, VFC cannot be 


specified. The default value is SVCl, which 
specifies that the device is to be assigned 
for SVCl access. 


Examples: 

The following example assigns an asynchronous line, PALO: to lu 
9 for SVC15 access. SRW access privileges and zero keys are 
assumed. 


AS 9,PALO:,,,SVC1L5 


The following example assigns the bisynchronous terminal for 
which an LCB was allocated in the first allocate example to lul 
with SRW access. 


AS 1,BSC1:RJE,IN 
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3.4.3 CLOSE COMMAND 


The CLOSE command permits the operator to close (unassign) one or 
more devices assigned to the currently selected task's logical 
units. 


Format: 


Parameters: 
lu is a decimal number specifying the logical 
unit assignments. 


ALL specifies that all logical units of the 
currently selected task are to be closed. 


Functional Details: 


Closing an unassigned lu does not produce an error message. A 
CLOSE command can be entered only if the referenced task is 
dormant or paused. 


Examples: 
The following example closes logical units 1, 3 and 5 of the 
currently selected task. 


CL 1,3,5 


The following example closes all logical units of the currently 
selected task. 


CLOSE A 
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3.4.4 DELETE COMMAND 
The DELETE command is used to delete currently unassigned LCBs 
from memory. 
Format: 
DELETE fd,[,fd.,...,fdan] 
Parameter: 


fa identifies the LCBs to be deleted. 


Functional Details: 


The LCB being deleted must not be currently assigned to any lu of 
any task. 
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| XALLOCATE } 


3.4.5 XALLOCATE COMMAND 


The XALLOCATE command allocates an LCB. If an LCB with the 
specified fd exists, it is deleted and an LCB with the same fd is 
allocated. 


Format: 


XALLOCATE fd, sane || 
80 


Parameters: 


fd is the file descriptor of the buffer or device 
to be allocated. 

ITAM specifies that the device to be allocated is 
a data communications device. 

lrecl is a decimal number specifying the logical 
record length of a data comunications device. 
It cannot exceed 65,535 bytes. lrecl may 


optionally be followed by a slash (/), which 
delimits it from bsize. 


bsize is a decimal number specifying the physical 
block size to be used for buffering and 
debuffering operations on the data 


communications device. 


' When ITAM is specified, bsize represents’ the 
buffer size in bytes. For ITAM buffers, this 
parameter cannot exceed the maximum block size 
established by the sysgen procedure. If bsize 
is omitted, the default value for the ITAM 
buffer will be the "standard" buffer size for 
the particular device. 


keys specify the write and read protection keys. 
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Functional Details: 


The XALLOCATE command differs from the ALLOCATE command in that 
if an attempt is made to allocate an existing LCB with the 
ALLOCATE command, an error message is given. With the XALLOCATE 
command, however, if the LCB to be allocated already exists, no 
message is generated and the LCB is deleted and reallocated. 
Otherwise, XALLOCATE and ALLOCATE behave in the same manner. 
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3.4.6 XDELETE Command 


The XDELETE command is used to delete one or more LCBs. 


LCB does not exist, no error is generated. 
Format: 
XDELETE fd, [, £2 his atts ,fdn | 


Parameter: 


fa | identifies the LCBs to be deleted. 
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CHAPTER 4 
DEVICE-INDEPENDENT ACCESS 


4.1 INTRODUCTION 


Device-independent access is designed for the noncommunications-~— 
oriented user who wishes to use data communications facilities 
without the trouble of direct line driver control. Such control 
is provided for the user by the OS/32 terminal managers. A 
terminal manager contains the logic to initiate, maintain and 
terminate a data communications link, thereby freeing the user 
from the need to control these line driver functions through the 
user task (u-task). For most basic communications tasks, use of 
0S/32 terminal managers is sufficient to accomplish the link. 


4.2 TERMINAL MANAGER ACCESS 


The terminal manager provides access to remote or local devices 
for the following uses: 


@® Programs that can access local or remote devices without 
recompilation. 


@e The noncomnmunications-oriented user who wishes to access 
remote facilities without knowledge of line protocols and 
codes - in addition to functions common to local and remote 
devices, terminal managers’ provide functions to connect and 
disconnect devices from a communications line. 


e The communications-oriented user who determines that a 
standard terminal manager provides adequate support for an 
application without special-purpose software. 


While data communications line drivers can communicate with 
different types of devices, the terminal manager is designed to 
support only a single device type or a group of similiar device 
types. 


In general, terminals can be accessed in either a buffered or 
nonbuffered mode. For nonbuffered access, data is transferred 
directly to or from the user buffer and every request from the 
user program requires at least one physical transmission over the 
communications line. 
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For buffered access, data is transferred between the user buffer 
and a system buffer. The terminal manager initiates data 
transmissions only when necessary. The system buffers needed by 
buffered access are contained in a system structure known as the 
line control block (LCB). Before accessing a terminal in the 
buffered mode, the LCB must be allocated in memory. At 
allocation time, the logical buffered terminal is given a name 
and the logical record length and block size are specified. 
After the program finishes accessing the terminal, the LCB can be 
deleted from memory. Supervisor call 7 (SVC7) calls or the OS/32 
command language provides the means to allocate, assign, delete 
or rename the LCB (see Chapter 3). 


In data communications, all terminal access, such as input/output 
(I/O) access, is accomplished via a logical unit (lu). Each 
terminal must be assigned to the proper lu prior to access. For 
nonbuffered access, the terminal is assigned to the lu using the 
name given to the terminal at system generation (sysgen) time. 
For buffered access, the logical terminal, named by a previously 
allocated LCB, is assigned to the desired lu. After the program 
has accessed the terminal, the lu should be closed. Chapter 3 
discusses the 0OS/32 support provided via SVC7 or the command 
language for assigning, checkpointing and closing logical units 
for terminal access. 


4.3 SEQUENCE OF OPERATION 
For a terminal manager that supports buffered access, the user 
must first allocate an _ LCB. The terminal is then capable of 


accessing data in either a buffered or nonbuffered mode. 


When a program is to be used with one type of buffered terminal, 
all required actions can be performed by SVC7 calls. 


To use the device-independent facilities provided by terminal 
managers, the following four steps must be performed. 
1. Sysgen 

Include terminal manager support by specifying the needed 


terminal (DCOD) at sysgen. Terminals are configured just 
like any local device, such as a line printer. 
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2. Programming 
Perform I/O requests by using SVCl as if the requests were to 
a local device or direct access file. Since all I/0 is 


performed to an lu rather than a specific device, device 
dependency is of no importance. 


3. Execution 


A nonbuffered device is assigned to the lu just as if it were 


a local device. For buffered devices, an LCB must be 
allocated prior to assigning the lu. The terminal manager 
uses this LCB to control access to the terminal. The LCB 
contains control fields, the device name and the required 
buffers. 


After allocating an LCB, assign the LCB to the lu used for 
program access. This establishes the link between the lu and 
the device named by the LCB. 

4. Termination 
Close the lu assigned to the device and delete the LCB from 


memory. The device is then available for another program. 


The steps outlined for execution and termination can be performed 
by the program via SVC7 requests or by the system operator 
through the OS/32 command language. 

In general, the sequence of operations necessary for terminal 
level access is: 

1. Allocate an LCB that reserves buffer Space and names a 


logical terminal (buffered access only). 


2. Assign the terminal or logical terminal to the desired 
program lu. 


3. Access the terminal via SVCl calls, similar to accessing a 
local device. 


4. Close the assigned lu when the terminal is no longer needed. 


5. Delete the LCB from memory (buffered access only). 
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4.4 SUPERVISOR CALL 1 (SVC1) 


The data communications SVCl facility is ideal for the 
noncommunications-oriented user. It allows the user to easily 
extend the range of a system beyond the computer room. Remote 
terminals can be added with no impact on user programs. 


All data transfers are performed at the read/write level. The 
OS/32 software performs the processing needed to interface with 
the terminal or protocol that frees the user of the _ problems 
generally associated with communications programming. 


By issuing a read/write SVCl to the OS/32 executive, the user can 
perform local or remote I/O. SVCl can be used directly by a 
Common Assembly Language (CAL/32) program or indirectly by a 
high-level language run-time library (RTL) routine. 0S/32 
provides extended options with SVCl to give the assembly-level 
user direct control over communication functions that have no 
parallel in local devices, such as disconnecting from a telephone 
line. 


Section 4.4.1 describes the SVCl functions for terminal access. 
The individual terminal manager description should be consulted 
for exact interpretation of function code and status. To write 
user programs that operate with either remote or local devices, 
see the SVCl description in the OS/32 Supervisor Call (SVC) 
Reference Manual. 


4.4.1 Supervisor Call 1 (SVCl) Parameter Block 


SVCl is used to initiate I/O for communications devices as well 
as local devices. The extended options field of the SVCL 
parameter block shown in Figure 4-1 is used for terminal manager 
access. The function code byte, interpreted for data transfer 
requests, is defined in Table 4-1. 


The SVCl parameter block must be 24 bytes long, fullword 
boundary-aligned and located in a task-writable segment. 
Location within a writable segment is necessary so that’ the 
status of an I/O request can be returned to the status fields of 
the parameter block. All fields in the parameter block are not 
required for every I/O request, but must be reserved (see Figure 
4-1). 
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2 bytes for status 

A(buffer start) 

A(buffer end) 

4 bytes for random address 

4 bytes for length of data transfer 
Y'extended options' 


SVCl Parameter Block Format and Coding 


is a l-byte field indicating whether a request 


is a data transfer or a command function, and 
the specific operation to be performed. Bit 
settings for data transfer requests are 
described in Table 4-1. Hexadecimal function 
codes for command function requests are 
defined in Table 4-2. 
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lu 


Device- 
independent 
status 


Device- 
dependent 
status 


Buffer start 
address 


Buffer end 
address 


Random 
address 


Length of 
Gata transfer 


Extended 
options 


is a l-byte field containing the logical unit 
currently assigned to the device to which an 
I/O request is directed. 


is a l-byte field receiving the execution 
status of an I/O request after completion. 
The status received is not directly related to 
the type of device used. 


is a l-byte field receiving the execution 
status of an I/O request after completion. 
The status received contains information 
unique to the type of device used. 


NOTE 


The device-dependent status byte, 
into which general purpose drivers 
return the low-order eight bits of 
the device address, is used 
differently for terminal managers. 
When an error occurs on a data 
communications device, the byte is 
used to differentiate between the 
possible specific errors within 
the general category given by the 
device-independent status. 


is a 4-byte field used only for data 
transfer requests’ and must contain the 
starting address of the I/O buffer that 
receives or sends the data being transferred. 


is a 4-byte field used only for data 
transfer requests and must contain the ending 
address of the I/O buffer that receives or 
sends the data being transferred. 


is a 4-byte field containing the address 
of the logical record to be accessed for a 
data transfer request; a legal hexadecimal 
number must be specified in this field if bit 
5 of the function code is set to l. 


is a 4-byte field used only for data 


transfer requests. It receives the number of 
bytes actually transferred as a result of a 
data transfer request. If an error occurs 


GQuring data transfer, this field is modified 
with indeterminate data. 


is a 4-byte field specifying device-dependent 
and device-independent extended functions that 
must be executed by the device when it is 
servicing a data transfer request. 
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If bit 7 of the function code is zero (Format), the 
interpretation is identical to the interpretation for other 
devices described in the 0S/32 System Level Programmer Reference 
Manual. The terminal manager will make assumptions’ using 
defaults where necessary. If bit 7 is set to 1 (Image), the 
extended options field is required. 


ee Oe ee ee ee nee Beet ce eee meee me ce meme mm en mt mm ee Be na ee ee ee ee es eH 


| F | R}widF {t{]wtis}aAtds] Pf Ef 
;c;dDiRio;aAjyc}yRi oO} 
Bits: 

0 1 2 3 4 5 6 7 


Figure 4-2 SVCl Function Code Field 


TABLE 4-1 SVCl DATA TRANSFER FUNCTION CODE 


ee cee Sm erm mame Gee; OY sutures mmo SY re ies mee eT, ms eee er ns Sate, emp See ees es See cn ms ge DM Sy ee ee ee mee te es cme) ee ee Oe re ees ey os Ree et Se ey ee tes ee 


BIT | MEAN ING 
O | Function code type 


This bit indicates the I/O function to be performed. 


1 Indicates an SVCl command function. If bit 7 is 
also set, no echoplex is desired for the next image 
1/0. 


ce, See ees cm i eee een ems eee mes MO SR eis Mes SS Meets ete Gets Me lS Mt ey Sy ee ee ee eS ee eee ee ce ee ee re ce Ge eee ee ee er Se ere me OS ON mE oe ee oe 


Read/write bits 


1 
| 
| 
! O Indicates a standard data transfer. 
' 
! 
| 
| 


j 

! 

| The meaning of these two request bits is modified by 
| bits 3 to 7 to control the transfer. Basically the 
{ four values are: 
' 

! 

| 


10 Read 

Ol Write 

11 Test and set 

00 Wait only or test 1/0 complete 
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TABLE 4-1 SVCl DATA TRANSFER FUNCTION CODE (Continued) 


MEAN ING 


ASCII/binary bit 


This bit indicates the type of formatting requested if 
bit 7 is set. 


0 Indicates ASCII formatting. The internal data is in 
the 7-bit ASCII character set and is translated to 
an equivalent character set appropriate for the 
external device. If image I/O extended option is 
specified, the data is translated and the appro- 
priate parity is added. 


1 Indicates binary formatting. The internal data is 
8-bit binary and will not be translated. Binary 
image is a straight 8-bit data transfer, no parity. 
If bit 3 is set and an image I/O extended option is 
specified, the internal data byte (eight bits) is 
transferred without translation. 


{ 

| 

4 | Proceed/wait bit { 

| ! 

I , { 

{ This bit indicates the action to be taken after an I/O | 

| is initiated. i 

' QO Proceed - indicates that control is to be returned \ 

' to the task after I/O initiation. | 

! ! 

f 1 

| 1 Wait - indicates that a task is to be put into I/0 H 

wait until the data transfer is complete. 

Site ee Set a a an ee ee oe as See ee ee oS ee a a a as a eh a is pace ees ma cae eo ooo ce ' 

5 | Sequential/random bit 

I | 

j { 

| O Sequential - indicates the next logical record is to } 

H be accessed. | 

| | 

| Ll Random - indicates the logical record specified by H 

H the hexadecimal value in the random access field is } 

H to be accessed. H 

cca Nr tsa he as et nese aes jc is (in “espa in ess ees pais “mm seem “eu ms is er enn ess eases ms Sa eh cme hi “ins ges ache ass ces Fees Se ics woe te “oder H 
6 Unconditional proceed bit 


H 

} 

| O Indicates the task is to be put into wait until the 
requested device/file is free. At that time, the 
request is processed. 
! 


1 Indicates that the request is to be rejected with a 
condition code of X'F' if the requested device/file 
is not free. 
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TABLE 4-1 SVCl DATA TRANSFER FUNCTION CODE (Continued) 


— ae ee ee ne oe -_ 2 me ee ee ee ee ee oe ee, ee ee — = ee ee oe oe —— — = —— me ed ee ee 
= SS SSS SS a SSS SS SSS SS SS SS SS SE SSS SSIS SS SSS TS ST SES SS ST TSE SE TSH ASS SE STS SS ISS SST ' 


7 Standard/extended options bit 


{ O Indicates standard device-independent data format- 
H ting is to be performed. 
' 
: 
} 
| 


1 Indicates that the extended options field is to be 
examined for additional formatting and line control 
options. 


— A eS nn seek ee meme mene SA mS seme Gee ene cee RA Se mm So em ey SD ee en ee Se es ee me eR Se me ee ee Se ne mn SE em nite Se ny eS ee SS a em enemy oe oy es 


The extended options field of the SVCl parameter block consisting 
of 32 bits, is defined in Table 4-2. Extended options provide 
both device-dependent and communications-dependent features with 


SVCl access. This allows a limited amount of formatting to be 
done by the program without having to use SVC15 line driver 
access. The capability to connect to and disconnect froma 


switched communications line (i.e., the ability to answer a data 
telephone call and to hang up) is also provided. The extended 
options can be used only in conjunction with a read or write 
operation, as explained in Table 4-2. 


If the user does not wish to use the extended options, 
connect/disconnect operations are controlled by the terminal 
manager. If an SVCl request is made to an unconnected switched 
line, a connect is’ automatically performed. When the last 
assignment to a switched terminal is closed, a disconnect is 
performed. 


For editing terminals (device codes 156 and 157), a user may 
specify no echoplex for an image I/O. Another option available 
for these device codes is 8-bit no parity data transfer. No 
echoplex is specified by preceding the image I/O with an SVC1 
command with the function code set to xX'81' and the extended 
options field set to ¥'1000 0000'. To indicate 8-bit no parity 
data transfer, the user must set the binary bit in the _ function 
code (X'10'). 


An in-depth discussion of SVCl data transfer functions and 


extended options can be found in the 0S/32 Supervisor Call (SVC) 
Reference Manual. 


48-077 FOO ROO 4-9 


TABLE 4-2 SVCl EXTENDED OPTIONS 


BIT | HEX MASK | MEANING 
0 ' 8000 0000 |} Connect | 


! 

{ 

1 

| When set, this bit instructs the terminal 
| manager to establish a connection over a 

| switched line before transferring data. It 
| is ignored for nonswitched configurations. 
| If the line has been sysgened with the 

| XDCD bit set, then all I/Os are errors 

f until an SVCl with the O bit set is 

| executed. See the System Generation/32 

| (Sysgen/32) Reference Manual for further 

} details. 


4000 0000 Disconnect 


| When set, this bit instructs the terminal 
| Manager to disable the data terminal ready 
| control signal to the adapter after the 

| Gata transfer operations specified in the 
} function code are completed. This allows 

| program-controlled disconnect of switched 
;} lines and control of carrier on leased 

| configurations. 


a oT OO eS Semen SOD coe NS SAS Gee OE Se Se ces ee ee eee es eee em eee ee mee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee 


2000 0000 Format/image bit 


OQ Indicates that no data formatting is to 
be performed by the terminal manager 
(image mode). 


performs all required data manipulation 
to convert between the terminal's 
required data format and one that can be 
used for transfers to other Perkin-Elmer 
peripherals (i.e., trim trailing blanks 
and stop 1/0 on the detection of the 
Carriage return (CR)). 


ere er cee ee em me me es ee ee em ce ee eee ee ee me me ee es en re ee ee cee eee Sa Se ee mee One ee ee Mi me Oe Cm Seles OR SE ces ce ee Ne Ye 


No echoplex 


i 1 Indicates that the terminal manager 
! 
| 
H 
' 
H 
H 
H 


with function code X'81' to specify no 
echoplex. 


ee ON Se TO eS RY SG OY ee ee Gee, ne mere mee ee Re me ee ey Se a me ee me ee ee eee ree me es ees ee me eee ce er ee me re ee ee ee re 


} 4-6 {| OEFEOO OOOO } Not ITAM-related. 


| When set, this bit is used in conjunction 
{ 
! 
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TABLE 4-2 SVCl EXTENDED OPTIONS (Continued) 


ed 


| BIT | HEX MASK | MEAN ING | 

| SSeS SSS SSSA S SSS SST SKS SK SSG Smee sess sss sees! 

| 7 | {| O = reserved 

| Sin, SS "Sr ins mA nnn. inna“ GSe us (stn ai, reac” minicar cms ee cma ce)! nk we eg nc a aol eh th aed “Sh a's acn i 
8 0080 0000 Vertical forms control (VFC) 


{ 9-15{ OO7F 0000 


16-31; 0000 FFFF 


a A a ee SD RN SNE MoS CNN NS tn Mate Gee Maly Ge Ge SEN Geet See eg ON MD SEED Geen GY One ewe Sen GE: GE Se St See ee Sues Ge Soy NEN Sone Gee Ge men ee: 


When set, this bit requests the V/C 
option for an ASCII I/O operation. 


Reserved for future device- independent 


options. All bits must be zero. 


Reserved for device-dependent options. See 


individual terminal manager 
for definitions. 


— a oe om 


ee me ee ee eee Meet eT Gate Gem tes OY ee 


descriptions 


PN Ne ce er eee ee Nee hr Re ne ree eR Na ene ce es eee ee ee eel anal 


48-077 FOO ROO 


CHAPTER 5 
DEVICE-DEPENDENT ACCESS 


5.1 INTRODUCTION 


Device-dependent support of communications devices is provided by 
OS/32 line driver access. For this support, the operating system 
is configured with communications lines that correspond to the 
hardware communications adapters present in the system. Through 
line driver access, different terminals can be supported at 
different times over the same line since the actual 
communications protocols and data formats are specified by the 
user program via supervisor call 15 (SVC15). SVC15 allows a 
program to specify a sequence of control commands and the data 
required by the control sequence. Line driver access supports a 
communications network with maximum efficiency and throughput by 
providing the capability to specify buffering techniques, monitor 
the progress of a control sequence, and alter control sequences 
and data while in progress. 


SVC15 is similiar to SVCl, but because of the specialized 
requirements of data communications, SVC15 has more variables and 
options. The SvVCl function code allows a task to request a 
single function, read, write, rewind, etc., on a single data area 
for each SVCl call. SVC15 allows a task to request a series of 
commands to be executed on a series of data areas. 


A key feature of SVC15 access is the flexibility allowed in data 
formatting. Driver commands may result in a variable number of 
data fields being accessed from the SVC15 parameter block; the 
exact number of data fields is dependent upon the command type. 
For example, the READ or WRITE buffer commands obtain either one 
or two data fields. Other command types use either one or no 
data fields. 


5.2 LINE DRIVER ACCESS 

The SVC15 call and line drivers provide access to remote devices 

for the communications-oriented user to: 

@ access devices with protocols or codes not supported by a 
terminal manager, 


@® use special buffering techniques because of time, memory or 
line use considerations, or 


@® use data or command chaining to achieve the throughput 
necessary for the application. ; 
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5.2.1 Sequence of Operations 


To use the device-dependent facilities provided by line drivers, 
perform the following steps: 


1. System generation (sysgen) 


Include line driver support by specifying the desired lines 
at sysgen. Lines are configured just as any local device, 
such as a line printer. 


2. Programming 


Perform communications line access by providing the control 
sequences and data necessary to support the remote device 
attached to the communications line. The control sequences 
and data are passed to the line driver through SVC15. Access 
to the line driver is by logical unit (lu), so different 
communications facilities of the same type can be accessed 
without recompiling the program. Further control is possible 
through the OS/32 Task Trap Facility, invoked when necessary 
by SVC15. 


3. Execution 


Assign the desired communications line to the lu accessed by 
the program. 


4. Termination 
Close the lu assigned to the communications line. The 
program can assign and close the lu via SVC7 or the 08/32 
command language. 
The steps outlined for execution and termination can be performed 
by the program via SVC7 requests or by the system operator 
through the OS/32 command language. 
Access to a remote terminal connected to a communications line, 
like access to a local device or terminal, is through an lu. The 
general procedure for SVC15 line access is: 
1. Assign the communications line to the desired program lu. 


2. Issue SVC15 to specify the initial control sequence and data. 


3. Use a trap-handling routine to monitor the progress of the 
control sequence. 


4. Modify the control sequence and/or data, or issue a 
subsequent SVC15 specifying new control sequences and/or data 
to continue communications. 


5. Close the lu assigned to the communications line. 
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5.2.2 Supervisor Call 15 (SVC15) and the Task Environment 


Execution of SVC15 affects the environment of the calling task 
differently than the execution of SVCl. SVC15 returns control to 
the calling task following driver activation (no input/output 
(I/O) and wait). It is the task's responsibility to synchronize 
processing with the ongoing I/O request. 


Driver control is specified by a driver command word (DCW). A 
DCW is actually a halfword that specifies to the driver a 
particular operation to be performed and certain options 
applicable to that operation. A DCW chain consists of 
consecutive DCWs with their respective chain option bits set. 
For further information on the DCW, see Section 5.5. The format 
of the DCW is shown in Figure 5-12. 


The SVC15 parameter block specifies the first entry in each of 

two related chains used to define the following requests: 

@e The DCW chain that specifies the sequence of driver operations 
(i.e., READ, WRITE, etc.). 

e The data field chain that specifies the arguments required by 


each driver command in the DCW chain. 


Figure 5-1 shows SVC15 access to a line driver. 
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SVC15 PARAMETER BLOCK 


’ DATA AREAS 


e DIRECT BUFFER 
e INDIRECT BUFFER 
e QUEVED-BUFFER 
LIST 
e CHAINED BUFFER 
e DCW PARAMETER 
e NEXT DATA-FIELD 
CHAIN 


Figure 5-1 SVC15 Access to a Line Driver 
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SVC15 activates the line driver to fetch and execute the first 
DCW in the DCW chain. Once autonomous driver execution starts, 
control is returned to the user task (u-task) with the condition 
code indicating the result of the call. If there is no error in 
initiating the operation by the first DCW specified, the status 
field of the SVC15 parameter block is set to indicate that the 
line driver is active with the request X'4000'. For the 
remainder of the I/O request, as each command operation is 
successfully completed, the next operation is fetched from the 
DCW chain and executed by the line driver. This sequence of 
fetch and execute is repeated until the entire DCW chain is 
interpreted or an error condition is encountered. 


5.2.2.1 Supervisor Call 15 (SVC15) Trap Handling 


The progress of SVC15 execution and the facilities provided for 
buffer management can be monitored by the task through the use of 
traps. The traps that can be generated for data communications 
are: | 


e SVC15 command execution trap 
e svcCl15 buffer transfer trap 
e SVC15 termination trap 


e sSvcl15 halt I/O termination trap 


Other types of traps can be generated for specific terminal 
managers such as the channel terminal manager (CTM). These traps 
are detailed in the appropriate manual. 


The traps listed above allow the task to synchronize execution 
with the concurrent processing of the SVC15 request. To enabled 
traps, bit 23 (TSW.ITM) of the task status word (TSW) must _ be 
set. When traps are so enabled and a trap-causing event occurs, 
the task trap-handling routine is given control before any 
subsequent task level instruction can be executed. Remember that 
the trap-handling routines operate at a lower priority than the 
line driver. Several entries can be made to the task queue 
before the trap-handling routine completes processing a single 
entry. See the 0S/32 Applications Level Programmer Reference 
Manual for more information on trap handling. 


When enabled by the appropriate bit settings in the TSW, the 
SVC15 function code and the DCW, a trap can be generated by 
adding one of the following reason codes and the address of the 
SVC15 parameter block to the u-task queue. 
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REASON CODE 


DEC IMAL (HEX) QUEUE ENTRY 
10(0A) . Command trap 
11(0B) Buffer trap 
12(0C) Termination trap 
13 (OD) Halt I/O trap 


5.3 SUPERVISOR CALL 15 (SVC15) PARAMETER BLOCK 
SVC15 specifies a control sequence and its associated data to the 


data communications line driver. The format of the SVC15 
parameter block is illustrated in Figure 5-2. 


{0(0) }1(1) 12(2) H 
\ Function : | | 
{ code H lu H Status H 
ee me em ee ee me em ee ie te ew ee mo wre ee oe ee ee ee ee eee ee ee ee oe H 
4(4) 15(5) { 

Command i { 

Number H Pointer to DCW chain \ 
es am at i aes came ee ha em em oe be ewe eee ee, ee ee ee ee oe eee ee se ee ee H 
8(8) }10(A) 


12¢C) {13(D) H 
{ | 
Data code 1 } Pointer to data field 1 | 
I a neta sr ama a a a aa aa a at H 
}16(10) 117(11) 
LH 1 { 
i Data code 2 } Pointer to data field 2 ' 
Wiese Se tee ees ea Sessa a im fami cs ce“ Pa mes," ems SS ase esa aan nem “Sess el dr a a nc ie i a Sa a i aL ee i) 
H i 
ge a a al ae a aa Sa H 
{4n+8 4nt+9 


ee a ree ee re eee ae ec ee ea ee ee ee ee ee ee ee ee 


svc 15, parblk 


ALIGN 4 
parblk DB x ‘function code' 
DB x ‘lu! 
DS 2 bytes for status 
DS l byte for command number 
DC 3 bytes for DCW chain address 
DS 2 bytes for length of last read 
DS. 2 bytes for length of last write 
DB 1 byte for data code l 
Ds 3 bytes for data field 1 address 
DB l byte for data code n 
DS 3 bytes for data field n address 


Figure 5-2 SVC15 Function Code Format 
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5.3.1 Function Code Field 


The first byte in the parameter block is a function code provided 
by the u-task. This field specifies options that apply to all 
Griver commands in the DCW chain executed by this SVC15. Figure 
5-3 shows the composition of the function code byte and Table 5-1 
shows the bit settings of the function code field. 


E | Reserved 
R | (reset to zero ) | 


oN OS DS SD ey EN RD SD AND OEE SN en NS SS I Me AI SY GD GE cm ee ND eS GN SO ies cee enh 


Figure 5-3 SVC15 Function Code Format 


TABLE 5-1 SVC15 FUNCTION CODE BIT SETTINGS 


ee ee mm me mS Me eee oe eS me mm eee meee mS Sap Se SR eee SM eee eee ce ee es me ee es ee me ee ee ee ee ee ee ees ee ey ee we ee me ee ey 


BIT MASK | MEAN ING 
0 X'80" | HALT I/O (HA) 


An SVC15 request with this bit set indicates 
that a task is requesting to halt an I/O that 
it previously started to the indicated lu. The 
program status word (PSW) condition code after 
the request indicates the results of the halt 
I/O call. Traps will not be generated for the 
halt call itself. 


cc = O The halt I/O was accepted, the orig- 
inal request ends with a halt I/0 
status and the command number field 
is updated accordingly. If the orig- 
inal request specified termination 
traps, a trap is generated when the 
I/O terminates. 


If the original request was in error 
recovery, then the original error 
status may be returned at termination 
rather than a halt I/O status. 


CC 


i 
r 


The halt I/O was not accepted be- 
cause the driver was not performing 
SVC15 I/O to the specified task lu at 
the time of the call. The _ status 
field is not changed. 


we we er nm nr rn a re ee re ee ee we ee = et 
ee 
were meee meee me te wee ee em ee me ee ere ee ee ee, ee ee ee we eee we ee tee ee 
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TABLE 5-]. SVC15 FUNCTION CODE BIT SETTINGS (Continued) 


a i A EY i a ca A ee Fe ES ES omy SL SS Se me SS cee Che SEN GE mene mE einey Remy WED Ge GE em ewee Gorm GNP Sher meh mom sem oie meet Ree ele ee me ee ee mee ee ae ene ey SR te mm ee ee en ee 


MASK | MEAN ING 


| 
U 
VSS SSS SC CSS SS SS SSCS BOSS SBCBSST SSMS SES SEE SSE SS eS KE 


X'40' | Command queue entry enable (CE) 


it 
it 


| 

| 

! 

| This bit must be set, along with the corre- 
| Sponding bit in the DCW and the enable SVC15 
{ queue entry bit in the TSW, to allow a trap at 
| the start of each DCW execution. 


Buffer queue entry enable (BE) 


i This bit must be set, along with the cor- 
| responding bit in the DCW and the enable SVCc15 
} queue entry bit in the TSW, to allow a trap at 
i the start of buffer use associated with the 
| DCW. 


Termination queue entry enable (QE) 


| 

; This bit must be set, along with the enable 
} SVC15 queue entry bit of the TSW, to allow a 
| trap on completion, normal or abnormal, of an 
| SVC15 call. A halt I/O call does not generate 
} a trap. However, the call being halted does if 
| termination queue entry enable was specified. 


me ee em ee ee ce oe ee es es ce es ce Se ee ee ee ee ee eee ce ee ci re et ee ee ee ce ee ee ee ec es eee ee ee ee ee ee ee ee ee ee ee ee ee ee ee 


Continuous error processing (ER) 


Setting this bit permits some errors to be non- 
terminating during continuous read operations. 


Reserved 


These bits are reserved for future use and must 
be zero. 


eT Ne ee ee Be ee Be ee ee De ee ee eed 


5.3.2 Logical Unit (lu) Field 


This byte identifies the lu to which the communications line is 
assigned for the transfer. A valid data communications device 
must have been previously assigned to the specified lu for SVC15 
access. : 
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5.3.3 Status Information Field 


The completion status of the SVC15 operation is returned to the 
system via the status information field. The format of this 
halfword is shown in Figure 5-4; the meanings of each bit setting 
are listed in Table 5-2. The termination codes resulting from a 
terminated SVC15 command are listed in Table 5-3. While 
processing an SVC15 request, the completion status of each DCW is 
maintained internally in the same format. 


ee ee ee ree eee re ee nee re ee ere me ee cree ne em cm cre mee mre re ee ree ee ne ee ee ee ee me ee ee ee ee 


bl 
wo 
G 
> 
i] 
ta 
x 
4 
uv 
> 
4 
> 
Q 
— 
ts 
Q 
R 
n 
os 
: 
s 
Q2 
: 
io! 
4 
tH 
v2) 
bi 
z 
QO 
le) 
si 
3 
s) 
4 
3 
Zz 
> 
= 
fe) 
Z 
Q 
fe 
o 
& 


oe ee ee ene ene en en ne en nn ne ee el een iteatetntantiantaainntinndandeatiantentadee teen ed 


Figure 5-4 SVC15 Status Field Format 


TABLE 5-2 SVC15 STATUS BIT SETTINGS 


ee mee a Se meee eee rm me ee em es me eet meee ete me ee cme me cre mn ce ee cet re ee me ee es ee ee ce ee cm ce eee ee ee ee ee ee ee ee es me ee 


' BIT | MASK } MEANING 
1 =O ! X¥'8000' } Error : { 
H H | Set for error condition. Bits 3, 4, 5 and } 
} any termination code greater than 2, in | 
1 i | bits 10 to 15, are considered errors. i 
aaa a a a a a ea aaa ea a ame) 
f J i X'4000' |; Busy 
| Set when the driver is busy with an SVC | 
1 | } request and can be cancelled via halt I/O. } 
{ H | The SVC15 parameter block status halfword | 
| } {| is initialized to this value and cannot } 
| i terminate with this bit set. ' 
[Sea SS SS Se SSS Sa ae ae ee ee eae ees See eee ees 
; 2 ; X¥'2000' {| Transfer not begun H 
H | This bit is set if read operations do not } 
; receive the proper required starting | 
H | } control characters (e.g., for binary | 
} synchronous). 
Une ie ly mse “sb ti a ais Vs Svs Pei Ja) so: sms wis caus cae secs nn talon ii ls “naa ates “toa Haat easy GT Set 1 
FE poe ET eae eR, wD PL yh TROL gage on ERIN ne ET ee AP a Ny SMS Ney tad Me Ng a ete AL a Gt een hea Sa een eg e ee  e t 
3 X'2000' Time—-out 


. ! 
| | 
i This bit is set if an entire command had } 
; not executed when the error timer expired. | 
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TABLE 5-2 SVC15 STATUS BIT SETTINGS (Continued) 


em tee re me em eee mr cece mee ee es meee Ce Ru ene ee Eines ee: mews ns ee cm Se ems Ouse StOrE meray eee SE Sete te me es tem me eee re re en te ee tee ee ee 


MASK ; MEAN I NG 


BIT 
4-5 


' xXx'ocoo' | Data check 


X'0400' redundancy check (CRC) or longitudinal 


' t 
1 ( 
! J 
; X'O800' | Received data with parity, cyclic 
{ ' 
t ' 
H {| redundancy check (LRC) error. 


; 6-7 } X'O300' | Driver-dependent 

H } X'O200' } 

| } X'O100' | 

| fn pare fm cane cee CO er sae EE GED arte SY mE GOD GEN OOH mem tems Sieh sore mate WED cm coon min minh mech tm Guts Geen Mmee“tiney cise GO eam A city Sy vue suit Sutae Coat ty SEED ins ane Sie oes mere Se men amy tes eres Gis ee on so eee ee 

; 8-9 ; X'OOCO' | Special Bhat seear detection 

! i ' 

! I ) 

| X'O080' |; Drivers can flag reception of special char- 

| X'0040' |; acters by setting these bits. 

H St a et a is cc a eee Ss ase es J cw ev a sc ase macy ca a ae get owen eS ali ems fa a ees en 

| 10-15 } X'OO3F' | Encoded Termination Code 

{ ' i 

' 4 ! : 

H H } Cause of piensa termination; see Table 5-3. 

TABLE 5-3 SVC15 ENCODED TERMINATION CODES 

| VALUE | 

DEC 

| (HEX) | STATUS MEAN ING 

H SESRESBCBTETEECBREBBBEACCEACBCBKECCBISHeESTESBTEVBVASEBSsESS SSeS LS SSS SKS EtST TSS SS as 

tf O(00) | No errors | No errors detected 

\ aac as hs Ea os ceca SS ee ty: sc asad vs eae hs anaes faces Vs "Ses" tes ies mee snes omen aa aoe ates sams Wan Ss a Tice” cco Ge ccna ens "a Ve ed ad eee RR 

, 1(01) | Reserved | 

} 2(02) } Line delete | Lime delete detected during read 

' eens ese ey ‘cei “Sans ces ncn ens ain in: ei: in ls pe Ba ie ce a i la ns as a i ‘sa ee mt es 
3(03) Break on write Break detected during an asyn- 


‘] 

i} 

' chronous write 

Break detected during an asyn- 
chronous read 


came Gimme aime are ents ME) ens eG SE frm enemy GND NE) Ae EA fat GE MAD MODY GOED GOD GEE Glee) GER GENES Gime Ces WETS meee oem MONE Ee Guy GE ee mune Sleee Sue SEE en me cm mee Se me me ee cs cme Se Sn cums ee Ste meee erty Se erm em COE mine OO 


; 5§(05) | Data check | BCC, LRC or parity error caused 

| | } termination (bits 4 anda 5 

| ! | specify exactly) 

| ee ee ee ce ee cee ee ey me ne eet eee ree eee me ce ne Se cae eee me Oe re ree em Os nee cn ere me ee eee ee ae ae me ce ee ee ee ee cae te eo ee a 
6(06) Buffer Limit Buffer limits reached (no 


i} 
! 
| proper ending sequence, binary 
} synchronous ) 
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TABLE 5-3 


SVC15 ENCODED TERMINATION CODES 


(Cont inued ) 


eee ee eee re ee ee ee eT Ge ce SE GS ones ee Re Ge Ge eee Gee See ee eee Ge GES cee ae ee cee ee ene ee ee ee cme cee me eee ee ee ee ee ee come aes me UE Oey ERD cette ORM Cente ened. ris Seat me me 


STATUS 


Bad pad 


MEAN ING 


PAD character (not received 


binary synchronous 


) 


' 
i 
' 
{ 
{ 
SAS SSSA SSCS SS SSTS TGS SSS ESTAS SST SSS SS SSS STE S SSeS Sa ee | 
t 
i 
{ 
' 
' 


te en See Rt) SY SD UE NEY MAME Sie GSS GEE GEE EE SED See GES GEE GES SE GSY NUE SUED GE ES GS SUED GEER GEE GWE mY MED GED GEES me ere me cm. ene em GEE SUED Sine Owe GENE GE Gr GE HWE GONE Wl Gilmy Mie mums Amu siemy enn Gem ue Rn 


| 7(07) 
! 


ees eee ee Nene me me ee eee eee eee ee ee ee ee ee ee ee cee ee ee ee ee ee ee ee ee See ee ee ee eee ee ee ey Se MS Mele aoe, Me Ot call SEU OY ly een Reel GS ORE ED ne OID am nme feet eet 


18(12) 


ready 


Device 


Task queue 
error 


Framing or stop b 
chronous 


Reverse channel er 
nous . 


ee ere ee ee eee ne ee ee ee me eee ee ee em ee ee ee ee ee ee er ee ee ee ee ee ee ee ee ee ee ee ey ee ee ee Ge ee OE eee ee ee ee es ee ee 


it error asyn- | 
‘ 
t 


ror asynchro- 


Ring signal detected during data | 


transfer 


Busy and/or done b 


buffers not proper 


Task queue full, 


nonexistent during attempt to 


trap (amount of da 
questionable); er 
writes previous 

reported via traps 


Next I1/0 buffer 


on ee ee ee rms mee ee SY Gee ee One ee ee eT Se SE GE Se GEES Ge GE eee Ge me Oe ee Ge ee ee ee ee YS ORE GN GE EE See Mm Gene cme Gee Ee ee eee om me me ene cere ty ee) es at 


f 
its in chained |} 
ly set t 


invalid or 


ta transferred 
ror code over-— 
error codes 


_—ap ame amen ame eee ee eee eee 


not reset in 


en Se cn eS A SE Ne SD Gee See Se are Shee cit Gene emt GD Fe ee MD YE GES GS GE Ge EEE ORS Ge EEet GR GE BOE SEE Om Swe CEE mY Wwe ene Guy Gil GttY Sete EE Gee i Sm Gu GH Mem erik mH amen mare onan 


Halt I/O request; 


J 
§ 
aborted I/0 { 
t 
t 


22(16) 


Transparent 
block size 
error 


Data buffer is sma 
transparent block 
synchronous only) 


lier than the } 
size (binary | 
| 
1 
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TABLE 5-3 SVC15 ENCODED TERMINATION CODES (Continued) 


| VALUE | 

| DEC | 

} (HEX) | STATUS H MEAN ING 

| SSpeSVak eis RRR BRIEABRSEBTSBVBVASCoSEeE SEAS BIS BCBS Vs BBLS STSEAsI S SBKBENMBO Bes = =z 
{| 23(17) {| Bad character | Improper binary synchronous 
{| sequence | sequence 

' a ek ie te ns RS, af ae ca a co is ce ans Se we sks ses esse een ues ime oS “este Sn Gi, mecha cet “eed eT aa 
} 24(18) {| Illegal command | Command or modifier not valid 

H sa: eS‘ ais an in ct ni Si a ‘ae a ee Ti ra i ar em Si kui: a en anc Su nese“ 
{| 25(19) | Memory fault 1 | Memory fault referencing data 

| ce es ew ne cee ve em mm cm same es mi ee ND sere Sham Cem an Sve mum ca, mat ten css Gn SEED cae EY tone nD fae ‘bin Sens seme ts Snes SD ea ee OS a es rare OE cS a ms oe see: me ee ee ee Oe 
{ 26(1A) {| Memory fault 2 i Memory fault referencing buffer 

H er a i s/s se en (a cm eae “Same le fe a a kf Sach She si a a kk ee, eis see 
{| 27(1B) | Illegal lu } lu illegal (not SVC1L5, not 
| assigned) 

\ eee me eee ee com ee es een me re mae ee fee enn tare cones em em cme ru nts Sy fem On Gems me sas Gm eee une ete es OD See om en mens ce ont, ce ms Su ee OD Mie Ses ce eee fe ee ee ee ses ee ene 
| 28(1C) | Illogical status | Device status not valid (pos- 
| i | sible strapping problem) 

H Bee Co ee ee a es a es a 


} 29(1D) | Power fail | I/O interrupted by power failure 
| ox cancel 


ee ee ee me em es ee ee, ee ee ee ee oe ee ene Ge eee ee eet Oe Ge Meee See ee ee ee eee ee ee ee ome OE Ge ee ee ee ee ee SS ee ee ee ee ee oe Oe Se ee ee es a ms ne oe 


{ 
1 
| 30(1E) | Illegal software | 
' ' condition \ 
J 
t 


} $31(1F) | Illegal H Illegal translation table speci- 
Ebane tare | £ied 

i sce ani ai win Si cn i is i di Ss “SS ual ts “ce si sn" ay te i, ‘iin ei a SS ts ek, a aes aa) Sh 
{ 32(20) {| Idle line i Idle line sequence received 
| H | zero-bit insertion/deletion 

| (ZBID) 

| ses Ss tam ae la, Sr cs a ma mh ls na hr Sa in iwi on si aie tne nn Si” a mr wm cn cm ‘i ses“ i ses at on 
! 33(21) | Frame abort | Frame abort character received 
i | ZBID 

i sm“ i oi en Sos “rs eve “on osGei. emr  SS aeaai  fsis  Sal-ce c>oanSS w ah cs Secmo l Ca ne 
|} 34(22) | Invalid frame | Received frame of incorrect 
| | {| length ZBID 

| jas aa ae cms wt is sea ominous Secchi an ine Gi tin Sms Som, sem “mes ma ao es “es i ce a a a a a cal ee en ee ee 
| 35(23) | Queue empty | Queued buffer list empty 

i tc: “ii 7 cle i “mich “a cr nei! chon ce ccm te mn em nh lint mi, i a a ani mt as Ses iy“ in“ me mc 
{ 36(24) | Queue overflow | Queued buffer list overflow 
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5.3.4 Command Number Field 


The fourth byte of the parameter block indicates the number of 
commands executed. The number of DCWs fetched and executed is 
maintained by the driver and returned to the u-task via this 
field. In the event of an error (or halt I/O), this counter 
indicates the number of the commands being executed when the 
error occurred; i.e., it equals 1 if only one DCW of the chain 
was executed. 


NOTE 


When this byte is incremented past 255, 
the SVC15 request is aborted and the 
status indicates that the number of 
commands executed overflowed, X'80l11'. 


5.3.5 Driver Command Word (DCW) Pointer 


This field must be set to the address of the first command in the 
DCW chain to be executed by the SVC15 call. 


5.3.6 Length of Last Read Field 


This halfword is updated by the driver termination to indicate 
the number of bytes transferred during the last READ command 
executed by SVC15. If no data was transferred or if no reads 
were executed, zero is returned. 


5.3.7 Length of Last Write Field 


This halfword is updated by the driver at termination to indicate 
the number of bytes transferred during the last WRITE command 
executed by SVC15. If no data was transferred, or if no reads 
were executed, zero is returned. 


For the length of the last read and the length of the last write 
fields, if a DCW string contains more than one READ or WRITE 
command, only the length of the most recent operation is 
reflected in this field. However, when chained buffers are used, 
the total number of bytes transferred to or from the entire 
chained buffer by the last READ or WRITE command is reflected. 
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5.3.8 Data Fields 


The remainder of the parameter block consists of data fields 
required by the DCW chain. As illustrated in Figure 5-5, each 
data field consists of a fullword divided into two sections. The 
last three bytes of the field contain a pointer to the data 
needed by the DCW (bits 8 through 31). This address could point 
to no data or to one or more data fields, depending on the 
particular command. The first byte (bits O through 7) consists 
of a data code indicating the type of data pointed to by the last 
three bytes. The data code also indicates the type of buffering 
desired. Definitions of the data code bit settings are detailed 
in Section 5.3.9. 


Ne ee ed 


Figure 5-5 SVC15 Data Field Format 


When the DCW associated with the data field is a READ or WRITE 
command, the data field points to a buffer. For other DCWs, the 
data field points to a parameter required by that DCW, such as a 
time value. The data field can also point to the head of another 
Gata field chain, allowing data field chains to exist in 
noncontiguous memory. 


5.3.9 Data Field Chain 

The SVC15 parameter block specifies the control sequence to be 
performed by pointing to a DCW chain. The first data field in 
the data field chain is at the fullword at offset 12(C) from the 


start of the parameter block. 


Table 5-4 details the bit settings of the data code byte of the 
data field. 
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TABLE 5-4 DATA CODE BIT SETTINGS 


ee ee ee ee eR eee ee ES eee Ste ee mee me ee cS Se ee PD Oe ee eed eee Goee Oe eee Eee See Ee Ret So OR ioe Ma Sm ei Gms tees wee 


| DATA CODE } } 
{ (HEX) | CONTENTS | 
| 00 | Pointer to direct buffer H 
O01 |} Pointer to DCW parameter 
H 04 | Pointer to indirect buffer | 
{ 08 ! Pointer to chained buffer i 
OA | Pointer to queued buffer list | 
80 


Pointer to next data field chain 


oe eS ie a NS EN oe cee AY Sm GERD Sm RS SONS ED GO SOD SEED SO Sie EY GEE SD ee ee AD DS OD OS We ON tele ee om TA ie ae Amn MR mie font ume 


Data codes 00, 04 08 and OA indicate that the data field contains 
the address of a data buffer that can be direct, indirect, 
chained or queued. 

Data code 01 indicates that the data field contains the address 
of a parameter required by a driver command, such as a time 
value. 

Data code 80 indicates that subsequent data fields are to be 
fetched from the specified address, allowing the data field chain 
to exist in noncontiguous memory. 

5.4 BUFFER TYPES 


SVC15 supports four buffer types: 


e Direct 
e Indirect 
e Chained 


@® Queued 


These buffer types are defined by the data fields in the SvcC15 
parameter block. 
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5.4.1 Direct Buffers 


A direct buffer is defined by two data fields containing the 
starting and ending addresses of the buffer, similar to an SVCL 
data buffer. The starting address points to the first data 
character and the end address points to the last data character 
(i.e., a l-character buffer has a starting address equal to the 
ending address). Direct buffers can begin on any byte boundary 
and require two data fields in the data field chain. Figure 5-6 
depicts a direct buffer. 


START 


{ 
1 
END | » BYTE N 


Figure 5-6 Direct Buffer 


5.4.2 Indirect Buffers 


An indirect buffer is specified by one data field containing its 
starting address. The buffer itself contains all required size 
information. The first halfword indicates the number of bytes 
available in the buffer. The second halfword of the buffer is 
updated by the driver and indicates how many bytes of data were 
actually transferred by the I/O. An indirect buffer must be 
aligned on a halfword boundary. Figure 5-7 depicts an _ indirect 
buffer. 
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i 
! 
HALFWORD H BYTES AVAIL =n t 
ALIGNED = | -----7 2-7-3727 - eH ane nn | 
H BYTES USED t 
| —_ ¢ 
 iioeeieetier hee ieeielasineatins tenia hae eer aa 
BYTE 1 | BYTE 2 
| —~—-— ene eee rere | 
BYTE 3 { BYTE 4 
| anne nnn nena nnn ane-=H-| 
H BYTE 5 {| BYTE 6 
| wane anna nnn nena naan n= | 
ow 
! 


Figure 5-7 Indirect Buffer 


5.4.3 Chained Buffers 


Chained buffers are specified by one data field containing the 
address of the first buffer in the chain. Chained buffers look 
very much like indirect text buffers, but have an additional 
fullword at the beginning called the link word that might contain 
the address of another chained buffer. Thus, two er more hyffers 
can be linked together into a chain. The last buffer in a chain 
of linked buffers contains a zero link word indicating the end of 
the chain. Figure 5-8 illustrates chained buffers. 


FULLWORD | FLAGS | LINK WORD 
ALIGNED Serge 


laa eel alae eel areal ee ced oneal nA ala, Rec aeee nate ere The Tne than Be Bho oe: Beas Mee Ree ne Rene io 


i 
| BYTE 1 {| BYTE 2 | BYTE 3 Zz BYTE 4 | 
\ - ; 
! ! 


Figure 5-8 Chained/Queued Buffer Format 
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Chained buffers can also be configured into a closed chain (a 
ring) by having the last buffer link back to the first buffer. 


The first byte of the link word is used for certain flags to 
indicate conditions or options within the buffer. Figure 5-9 
shows the format of the chained/queued buffer Link word flag byte 
and Table 5-5 details the bit settings. Chained buffers must be 
aligned on a fullword boundary. 


A task can manipulate the links and data of chained buffers while 
I/O is in progress. Bits O through 7 of the link word (the flag 
byte) are used for coordination between driver and u-tasks. 


er ee net ee ee ey ee eee me come Se my Se ee En ets te ee me et ee me ee ee meee ee ee oe ee 


| Reserved for driver use } 
i] t 
! 1 


Done (reset to zeroes) 
Bits 
0 1 2 7 


Figure 5-9 Chained/Queued Buffer Link Word Flag Byte 
TABLE 5-5 CHAINED/QUEUED BUFFER LINK WORD FLAG BYTE 


(BUSY) {| (DONE) | 

BIT O } BIT l | MEAN ING 
| Buffer is available for driver use. 
' The link word contains a valid address 
} Or zero. 
| The adariver is currently using this 
| buffer for I/O. The u-task must not 
| change data, size values, link word 
| or flags. 
| The driver finished using the buffer. 
' The driver will not use this’ buffer 
} again if it reoccurs in the chain; 
f 
t 


O 
oO 


i.e., a ring. U-task can now’ change 
any value and the bytes used reflect 
actual transfer. 


oO 


1 | Invalid setting. Driver treats it as 
| if busy and done = ll. 
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The driver attempts to set up two I/O buffers when chained 
buffers are specified. This means that if the task needs more 
than a single chained buffer for I/O, it must supply at least two 
linked buffers when the SVC15 call is issued. These two buffers 
are set up in internal buffers associated with this line. The 
first buffer is flagged as busy (bit 0 of link word set), a 
buffer trap is generated if enabled and I/O is started. 


If the link word of buffer 2 is valid, the driver fills buffer 1. 
When buffer 1 is exhausted, the driver receives a buffer limit 
interrupt, finds buffer 2 is available (busy and done bits reset) 
and uses this buffer to continue I/O. Meanwhile, a routine is 
scheduled to flag buffer 1 as done and buffer 2 as busy and to 
attempt to set up the first I/O buffer using the current link 


word of buffer 2 as a pointer. If this link word is zero, the 
current buffer is the last buffer of the chain and the I/O must 
terminate within it. If this link word is nonzero, it points to 


buffer 3. At this time, buffer 3 does not necessarily have to be 
available (busy and done bits reset) indicating that buffer 1 is 
done and buffer 2 is now busy as long as its address is specified 
in the link word of buffer 2. A buffer trap is again generated 
to the calling task, indicating that buffer 1 is done and buffer 
2 is now busy. Buffer 3 must be available before the next buffer 
limit interrupt. If it is not, a buffer overrun occurs, I/0 is 
aborted and the status reflects this overrun. 


For read-after-write (RAW), the driver looks ahead and sets’ up 
only one read buffer. Thus, if chained buffers are used for the 
read, only one buffer is set up in advance. When the driver 
terminates the write, one buffer is ready to perform the read. 
When the read uses chained buffers, a subroutine to get the next 


buffer is scheduled immediately after performing the 
write-to-read turnaround. The buffer trap for the read is 
performed after read I1/0 begins. Thus, having only one read 


buffer instead of two is useful when using chained buffers for 
both write and read. However, the buffer trap for the next to 
last write buffer must be identified by the task because the task 
must specify the second buffer in the link word of the first read 
buffer before the driver completes the write. 


Memory is used most efficiently by linking two or more chained 
buffers to form aring. See Figure 5-10. 


ee ee ee cee ee ee es ee eee, me ee ee eee ee ee eee en ey ee 


BUF 1 ' 00 A(BUF2) | BUF 2 } 00 A(BUF1) | 
Tecate perma esciecaas eras cae 
| CHAINED | ! CHAINED | 
BUFFER H BUFFER 
! NO. 1 1 = NO. 2 | 


Figure 5-10 Buffer Ring 
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When the busy and done bits = 11, buffer 1 is finished and the 
driver is using buffer 2, which would be busy. The task can now 
process the data in buffer 1 and reset busy and done. When the 
driver is finished with buffer 2 (busy and done set), it chains 
onto buffer 1 and, finding the busy and done bits reset, uses it 
to continue the I/O. Thus, one SVC15 request can continuously 
perform I/O as long as the task keeps ahead of the driver. 


5.4.4 Queued Buffers 


Queued buffers are specified by two data fields, each of which 
contains the address of a standard Perkin-Elmer circular list. 
List 1 specifies a queue of buffers from which the data 
communications subsystem removes buffers for I/O operations. 
List 2 specifies a queue of buffers being returned to the 
applications program following I/O activity. List 1 can coincide 
with List 2. See Figure 5-11 for a description of the standard 
Perkin-Elmer circular list. Buffers are removed from the top of 
List 1 by a Remove from Top of List (RTL) instruction. Buffers 
are returned to the bottom of List 2 by an Add to Bottom of List 
(ABL) instruction. 


077-9 
LENGE TES 
SLOT n 


0 15 16 31 


NUMBER OF SLOTS NUMBER USED 
| CURRENT TOP NEXT BOTTOM 
SLOT 0 


OCCUPIED 
SECTION 


Figure 5-11 Conceptual Circular List and Format 


The format of each individual queued buffer with an address in 
the list is identical to the format of a chained buffer. 
Restrictions for modifying the control fields of a buffer quring 
I/O are the same for queued and chained buffers. 


When an I/0 buffer is removed from List 1, the link address field 
is cleared to prevent any ambiguity in error verification and the 
address of the buffer is maintained solely within driver control 
storage. The buffer is, in effect, not available to the 
applications program during I/O. 
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The busy and done bits within the flag byte are used analogous to 
chained buffers. When I/O is complete, the buffer is returned to 
the bottom of List 2. Simultaneously with I/O operation, the 
applications task can add new I/O buffers to the bottom of List 
1 or remove completed buffers from the top of List 2. Only list 
processing instructions (RTL, Remove from Bottom of List (RBL), 
Add to Top of List (ATL), ABL) can be used by the task to modify 
a circular list. Any other attempt to modify circular list 
control fields can result in a loss of control. 


If the program attempts to return a buffer to List 2 and cannot 
because the list is full, a queue overflow (X'24') error 
termination results. The addresses of any buffers currently 
being used for I/O are then chained to the bottom buffer in List 
2 to return them to the task. As the list address field is 
initialized to zero at the start of I/0, the task should check 
the nonzero link field to detect buffers returned because of a 
queue overflow condition. 


The buffer trap mechanism is available for queued buffers. 
However, to conserve processor time, a buffer trap is generated 
only when a buffer is added to a previously empty List 2, 
indicated by the status returned by the last RTL or RBL. This 
technique requires a program to process all buffers in List 2 
whenever a trap interrupt occurs. 


In Figure 5-1ll, the first two fullwords of a circular list 
contain the list parameters. Immediately following the parameter 
block is the list itself. The first fullword in the list is 
designated Slot 0, with the remaining slots designated 1, 2, 3, 
etc., up to a maximum slot number equal to the number in the list 
minus one. A maximum of 65,535 fullword slots can be specified. 
(Maximum slot designation is equal to X'FFFE’.) 


The first parameter halfword indicates the number of slots 
(fullwords) in the entire list. The second parameter halfword 
indicates the current number of slots being used. When the 
second parameter halfword equals zero, the list is empty. When 
it equals the number of slots in the list, the list is full. 
Once initialized, this halfword is maintained automatically and 
incremented when elements are added to the list and decremented 
when elements are removed. 


The third and fourth halfwords of the list parameter block 
specify the current top of the list and next bottom of the list, 
respectively. These pointers are also updated automatically. 


5.4.4.1 Coding a Queuved Buffer Request 
Three separate areas must be coded with a precise format to 
facilitate the use of queued buffers. These areas are the data 


field chain, the circular list descriptor and the individual 
queued buffer. 
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The data field chain must be coded as in Table 5-6. Two fullword 
entries must be defined in the data field chain in order to use 
queued buffers. The first fullword provides the address of the 
circular list from which the drive can draw buffers for I/0; the 
second fullword provides the address of the circular list to 
which completed buffers are returned. Each fullword entry must 
contain a hexadecimal A in the high-order byte to identify the 
entry as a queued buffer data byte and each must be aligned on a 
fullword boundary. 


TABLE 5-6 QUEUED BUFFER DATA FIELD FORMAT 


a el Ae (A A SS SY SS ee eR Gen MD eS we mets Mant OE RE GBM Gen Sev See GOS EE GY Sue uy SUS ANS Gee come Mitty Gee cme mete eet me ce ey ree Se Oe 


{| DATA CODE | POINTER 
| BYTE O BYTES 1 THROUGH 3 
| SSS SSS SSP SS ASSES ee ee oes | 
OA | Address of circular list from which | 
| buffers are obtained 
| ee 


OA | Address of circular list to which 
| buffers are returned 


The circular list can be defined by a DLIST Common Assembly 
Language (CAL) direction or by the FORTRAN 32-bit run-time 
library (RTL) subroutine, DEFLST. 


Each individual queued buffer must be coded as a chained buffer 
shown in Figure 5-8. Its address is placed into the FROM buffer 
list. 


5.5 DRIVER COMMAND WORD (DCW) 


Each DCW is a 16-bit command that specifies a primitive operation 
to a line driver. Figure 5-12 details the DCW format and Table 
5-7 describes the DCW bit settings. Bits O through 3 are flag 
bits that indicate options in effect for the command; bits 13 
through 15 indicate the general type of command; bits 8 through 
12 identify the specific request; bits 4 through 7 are unused and 
should be reset to zeroes. Not all commands are implemented for 
each line driver. = 
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Reserved 
(reset to zeroes) {} Modifier {; Command |} 


E E O 
Bits: 
0 1 2 3 4 7 8 12 13 15 
Figure 5-12 DCW Format 
TABLE 5-7 DCW BIT SETTINGS 
} BIT { MEAN ING. \ 
| Same ESSE ESS SSS SESS ESS SSS SSS SS SS SESS SS SESS SS Se eee ee SS | 
; O {| CHAIN Command (CC) | 
i 
| | Set this bit to indicate that the line driver should | 
| | fetch and execute the next DCW in the chain. If } 
| | reset, the SVC15 request terminates after executing | 
} this DCW. i 
[aS SSeS SS ee Se eee re eet ee = ee ee i 
i 1 | Command enable (CE) 
; 
H i Set this bit to specify that a queue entry is to be | 
| generated by adding a parameter consisting of the | 
| } address of the SVC15 parameter block to the task } 
| | queue with reason code 10 (0A) before executing this | 
| DCW. For trap generation, the appropriate enabling } 
H | bits must be set in the SVC15 function code and the |} 
H i TSW. If reset, no trap is generated. i 
H a mn, a rcs esac en a a Seem a Ye a See’ Si ese ee Se ns es ee Se soe es (See a Sos cee “a sem ep Se ee ts ee 
2 Buffer enable (BE) 


Set this bit to specify that a queue entry is to be 
generated by adding a parameter consisting of the 
address of the SVC15 parameter block to the task 
queue with reason code (OB): 


| O when processing the first character of any buffer 
H used by this command 

' 

’ 

| O before switching to the next buffer if chained 
buffers are used . 

' 

| 

H 

| 


To generate a trap, the appropriate enabling bits 
must be set in the SVC15 function code and TSW. If 
reset, no trap is generated. 
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TABLE 5-7 DCW BIT SETTINGS (Continued) 
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i BIT MEAN ING 


3 | Time-out (TO) 

! 

t 

| Set this bit to specify that an error time interval 
| is to be started when this command is fetched. If 
| the command has not completed before this interval 
} expires, the SVC15 request is aborted with time-out 
J 

| 

| 

| 

H 


status. The interval is given a default value at 
sysgqen time or can be modified by the MODE TOUT 
command. There are separate read and write time-out 
values. If reset, this command is not aborted 


because of time-out. 
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Command modifier 


These bits specify the particular command for each 
command type. 


Driver command type 


These bits specify the general type or primitive 
requests as follows: 


VALUE TYPE 
i t I 
f ! I 
| 000 NULL | 
001 CONTROL ! 
010 READ 
O11 PREPARE 
100 WRITE | 
101 HOLD 
| 110 MODE 
111 TEST 


5.6 LINE DRIVER COMMAND TYPES 


This section describes the commands for each driver command type 
with the binary and hexadecimal value of bits 8 through 15 of the 
DCW for each. These descriptions refer to signals generated by 
the communications adapter hardware. For all commands, normal 
completion means that the next DCW is fetched. If no further 
DCWs exist, the SVC15 request terminates. Nonerror status 
conditions are noted by setting the appropriate bits in the 
status halfword; the status returned on termination can reflect 
several such cumulative conditions, i.e., special character 
detection. 
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5.6.1 Null-Type Commands 


There are four null-type commands, none of which issue 1/0. 
instructions to the adapter. A CHAIN command and command trap 
flags are valid. 


NUMBER OF 
COMMAND BINARY HEX DATA FIELDS 
NOP 00000 000 00 1 
WAIT 00001 000 08 1 
XFER 00010 000 10 1 
CXFER 00011 000 18 2 


516. 2.1 NO OPERATION (NOP) Command 


The NOP command performs no operation; one data field is fetched 
but not used. However, it must specify a valid program address. 
If the CHAIN command bit (bit 0) is set, the next command is 
fetched. 


5.6.1.2 WAIT Command 


The WAIT command suspends driver execution for a_ specified 
interval. One data field is fetched which must point toa 
halfword containing the value of a time interval in multiples of 
100ms. The driver waits until the specified interval expires and 
then continues execution (if the CHAIN command is_- set) or 
terminates (if the CHAIN command is reset). 


5.6.1.3 TRANSFER IN (XFER) Command 


The XFER command specifies the next DCW in a chain that does not 
exist in contiguous memory. One data field is fetched, if a 
CHAIN command is set, the next command to be executed is fetched 
from the address contained in the data field. Thus, a branch to 
a DCW is performed. 


5.6.1.4 CONDITIONAL TRANSFER (CXFER) Command 


The CXFER command tests the internally-maintained status of the 
SVC15 request. Two data fields are fetched. The first data 
field points to two halfwords, the first of which is logically 
ANDed with the current state of the logical status halfword. The 
result is compared to the second halfword of the pair, and if 
equal, the next command to be executed is specified by the second 
data field. Otherwise, command execution continues with the next 
command in the current chain. 


5-24 48-077 FOO ROO 


The CXFER command can be used to test for specific conditions as 
indicated by the logical status; the first halfword of the first 
data area contains a mask with a l in each bit portion to be 
tested; the second halfword of the first data area contains the 
value to be tested against (e.g., if one or more special 
characters were detected after a read, a different command 
sequence might. be desired). 


5.6.2 Control-Type Commands 


A CHAIN command, command trap and time-out are valid flag bits. 
There are four control-type commands: 


NUMBER OF 
COMMAND BINARY HEX DATA FIELDS 
EXAMINE 00000 O01 O1 1 
RING WAIT 00001 O01 09 0 
ANSWER 00010 001 11 0 
DISCONNECT 00011 O01 19 0 


5.6.2.1 EXAMINE Command 


The EXAMINE command returns the device status of the specified 
adapter in one data field. The value obtained specifies the 
address of a writable byte into which the status of the device is 
stored. The last known physical device status is fetched from a 
byte in memory (DCB.DVST) maintained by the driver during I/O. 
When the byte is nonzero, its contents are returned and the byte 
is reset to zero. When the byte is zero, a sense status is 
performed on the device and its present status is’ returned. 
Thus, two EXAMINE commands should be suggested. The first will 
return the last status that caused the last error. The second 
will return the active device status at this time. 


5.6.2.2 RING WAIT Command 


The RING WAIT command suspends fetching of DCWs until a ring 


signal is received for the adapter. Interrupts from the adapter 
are enabled, but the data terminal ready lead to the modem is 
not. This command fetches no data fields and terminates when a 


ring signal is received from the adapter. When a CHAIN command 
is set, execution continues with the next command. Otherwise, 
the driver terminates. When time-out is set, the command waits 
as long as the value specified in the write timer halfword; when 
this interval expires, time-out error status is set. If time-out 
is not set, the command waits indefinitely for a ring signal. 
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5.6.2.3 ANSWER Command 


The ANSWER command terminates immediately for mnonswitched lines 
and switched lines that are already connected. For dial-in lines 
not connected, the data terminal ready lead to the modem is 
enabled, causing the modem to answer the incoming call. The 
command terminates when the data set indicates it is ready for 
I/O. TIME-OUT and CHAIN commands are handled as described in the 
RING WAIT command. 


5.6.2.3 DISCONNECT Command 

The DISCONNECT command disconnects from a switched line. The 
command resets the data terminal ready lead to the modem, 
suspends DCW fetching for one second and continues to the next 
command (if the CHAIN command is set) or terminates (if reset). 
5.6.3 Read-Type Commands 


A CHAIN command, command trap, buffer trap and time-out are valid 


flag bits. There are three read-type commands. When response 
time is critical, these commands must immediately follow a 
wr ite-type or prepare-type command to use RAW OL 


read-after-prepare-lookahead. 


NUMBER OF 
COMMAND BINARY HEX DATA FIELDS 
READ BUFFER 00000 010 02 lor 2 
READ 1 00001 O10 OA 1 
READ 2 00010 010 12 1 
5.6.3.1 READ BUFFER Command 
The READ BUFFER command reads data into specified buffers. One 


or two data fields are fetched, depending on the buffer types. 
The data fields specify a buffer or buffer chain into which data 
is read. The first byte of the first data field fetched 
specifies whether the buffer type is direct text, indirect text, 
chained or queued buffers. If the buffer type is direct text, a 
second data field is fetched. 


5.6.3.2 READ1 Command 
The READ1L command reads one character into the specified 
location. One data field is fetched, containing the address of 


a byte in writable memory into which a character is to be read. 
No alignment is required. Data code must specify X'Ol'. 
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5.6.3.3 READ2 Command 


The READ2 command reads two characters into the specified 
locations. One data field is fetched, containing the address of 
the first of two writable bytes into which two characters are 
read. No alignment is required. Data code must specify X'0Ol'. 


5.6.4 Prepare-Type Commands 


A CHAIN command, command trap and time-out are valid flag bits. 
There are two prepare-type commands. 


NUMBER OF 
COMMAND BINARY HEX DATA FIELDS 
PREPARE 00000 011 03 L 
PREPARE3 00011 O11 1B L 


5.6.4.1 PREPARE Command 


The PREPARE command suspends DCW fetching until the _ specified 
character is received from the adapter. One data field is 
fetched, pointing to a byte that contains a match character. 
Characters are read from the line until one is detected that is 
equal to the match character, there the command terminates. If 
the PREPARE command is chained to a READ command, the READ will 
take effect immediately because of the read-after-prepare 
lookahead. 


5.6.4.2 PREPARE3 Command 


The PREPARE3 command is an asynchronous driver command only. The 
command sets a 200ms timer each time a character is received. 
The command ignores all line errors (parity, stop bit, etc.) and 
terminates if the timer expires or the match character is 
received. 


5.6.5 Write-Type Commands 


A CHAIN command, command trap, buffer trap and time-out are valid 
flag bits. There are three write-type commands: 


NUMBER OF 
COMMAND — BINARY HEX DATA FIELDS 
WRITE BUFFER 00000 100 04 lor 2 
WRITEL 00001 100 oc a 
WRITE2 00010 100 14 L 
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5.6.5.1 WRITE BUFFER Command 


The WRITE BUFFER command writes data from specified buffers. One 
or two data fields are fetched, depending on the buffer type. 
The data field specifies a buffer or buffer chain from which data 
is written to the line. The left-most byte of the first data 
field fetched specifies whether the buffer type is direct text, 
indirect text, chained buffers or queued buffers. If the buffer 
type is direct text, a second data field is fetched. 


5.6.5.2 WRITE1 Command 


The WRITE1L command writes one character from the _ specified 
locations. One data field is fetched, containing the address of 
a byte from which a character is written to the _ line. No 
alignment is required. Data code must specify X'Ol'. 


5.6.5.3 WRITE2 Command 


The WRITE2 command is used to write two characters from specified 
locations. One data field is fetched, containing the address of 
the first of two bytes from which characters are written to the 
line. No alignment is required. Data code must specify X'OL'. 


5.6.6 Hold-Type Commands 
A CHAIN command and command trap are valid flag bits. There is 
one hold-type command. 
NUMBER OF 
COMMAND BINARY HEX DATA FIELDS 


HOLD SPACE 00000 101 05 L 


5.6.6.1 HOLD SPACE (Line Break) Command 


The HOLD SPACE command puts the line in a space (zero) condition 
for a specified interval. One data field is fetched, containing 
the address of a halfword with a time value in units of 100ms. 
The line is held in a continuous space (zero) condition for this 
interval. This command is valid for asynchronous communications 
only. 
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5.6.7 Mode-Type Commands 


A CHAIN command and command trap are valid flag bits. ‘Mode-type 
commands are used to change various default values in the DCB 
that are maintained by the driver. If the default value 
specified in the individual driver description is acceptable, a 
mode-type command is not necessary. Once a value is changed by 
a mode-type command, the only way to restore the default 
condition is by a mode-type command specifying the correct value. 
Coordinate such modifications if access is being shared by more 
than one program. There are ten defined mode-type commands: 


NUMBER OF 
COMMAND BINARY HEX DATA FIELDS 
MODE TOUT 00000 110 06 L 
MODE CMD2 00001 110 OF L 
MODE RCMD 00010 110 16 L 
MODE WCMD 00011 110 LE L 
MODE RDISABL 00100 110 26 Ll 
MODE WDISABL 00101 110 2E Ll 
MODE DISC 00110 110 36 L 
MODE SYNCNT 00111 110 3E L 
MODE TRANSL 01000 110 46 1 
MODE SPCHAR 01001 110 4E L 


5.6.7.1 MODE TOUT (Time-out Interval) Command 


The MODE TOUT command sets the error time intervals for commands 
that enable the time-out flag. One data field is fetched 
containing the address of the first of two halfwords; the first 
halfword contains an error time-out interval for read-type 
operations, the second contains an interval for write-type 
operations. Both are in one _ second units. The data field 
pointer to the two halfword parameters should point to a 
fullword-aligned address. 


This timer is strictly for error detection; when it expires, the 


SVC15 call terminates in error. Interval timing is performed via 
the WAIT command, which uses a separate (100ms resolution) clock. 
The resolution of the time is accurate to +0, -1 second. 


Time-out values should therefore be set to the desired number of 
seconds plus one. 


5.6.7.2 MODE CMD2 (Adapter) Command 


The MODE CMD2 command specifies the device-dependent command used 
to set adapter options. One data field is fetched with the 
address of a byte containing the device command that should be 
output to specify programmable adapter options such as parity, 
number of data bits, etc. 
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5.6.7.3 MODE RCMD (Read) and MODE WCMD (Write) Commands 


These commands specify the device-dependent commands to set’ read 
or write mode in the adapter. One data field is fetched for 
these commands, with the address of a byte containing the device 
command to be output for read or write data transfers, 
respectively. This command should enable interrupts. 


5.6.7.4 MODE RDIS (Read Disable) and MODE WDIS (Write Disable) 
Commands 


These commands specify the device-dependent commands used to 
quiesce the read or write side of the adapter. One data field is 
fetched with the address of a byte containing the device command 
to be output to set the quiesce read or write side of the line. 
These commands should disable interrupts. 


5.6.7.5 MODE DISC (Disconnect) Command 


The MODE DISC command specifies the device-dependent command used 
to disconnect the adapter from the _ line. One data field is 
fetched, with the address of a byte containing the device command 
to be output to disconnect the communications line (reset data 
terminal ready). 


5.6.7.6 MODE SYNCNT (SYNC Character Count) Command 


The MODE SYNCNT command specifies the SYNC character count. One 
data field is fetched, with the address of a byte containing the 
number of leading SYNCs transmitted (synchronous drivers only). 


5.6.7.7 MODE SPCHAR (Special Character Enable Masks) Command 


The MODE SPCHAR command sets up the bit masks necessary for 
special character detection. One data field is fetched, 
containing the address of the first of two halfwords; the first 
has a bit mask used to enable recognition of specific special 
characters during read-type operations; the second contains a bit 
mask used to enable special character recognition dur ing 
write-type operations. 


5.6.7.8 MODE TRANSL (Translation Options) Command 
The MODE TRANSL command specifies translation options. One data 


field is fetched containing the address of a byte with a series 
of indicators controlling translation options. 


5.6.8 Test-Type Commands 


Reserved for driver-dependent on-line test functions. 
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CHAPTER 6 
DATA COMMUNICATIONS STRUCTURES 


6.1 INTRODUCTION 


This chapter describes the internal operation of the various 
structures and subroutines that must’ be added or modified to 
include the Basic Data Communications Subsystem in the operating 
system. 


The Basic Data Communications System Support Module includes many 
subroutines that are called from the line drivers. These 
subroutines are involved with interfacing the driver with the 
operating system and with common buffer management and command 
fetching operations. 


6.2. DATA COMMUNICATIONS LINE DRIVERS 


The most obvious differences between data communications line 
Grivers and the general-purpose drivers are: 


e Parameter blocks 
e Supervisor call 15 (SVC15) instead of SVC1 


@e Format of the device-dependent portion of the device control 
block (DCB) 


e Event service routine (ESR) 


Normally, the driver schedules the ESR itself from the 
interrupt service (IS) state. However, the operating system 
executive might also schedule the ESR because of a time-out, 
cancel, power fail or the close of a logical unit (lu) during 
input/output (1/0) by the calling task or command processor. 


The OS/32 Basic Data Communications System Support Module 
includes many subroutines that are called from data 
communications line drivers. These subroutines are involved with 
interfacing the driver with the operating system and with common 
buffer management and command fetching operations. Some of these 
subroutines are exclusively for driver use, but have been 
included in this module to reduce code duplication between 
drivers. 
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6.3 CONTROL BLOCK FORMATS 

This section describes the control blocks and other system 
structures used in data communications. The following structures 
will be discussed: 

@® Device control block (DCB) 

e Line control block (LCB) 

e Channel control block (CCB) 


e Drop control table (DCT) for zero-bit insertion/deletion data 
link control (ZDLC) communications 


@® Drop definition table (DDT) for ZDLC communications 
@® DCT for asynchronous multidrop communications 


@ Drop access table (DAT) for asynchronous multidrop 
communications 


e Input/output block (I1OB) for asynchronous multidrop 
communications 


@ Station descriptor table (SDT) for 3270 emulator 
@ DDT for 3270 emulator 
@ Input/output handler (IOH) 


@ File manager handler (FMH) 


6.3.1 Data Communications Device Control Block (DCB) 

The data communications DCB provides a table-driven mechanism for 
line drivers and terminal managers. It contains parameters and 
system information, such as addresses of line driver/terminal 
manager modules, addresses of task control blocks (TCBs) and user 
parameter blocks and specific device-related fields. The DCB 
structure is divided into three portions: 

@ Device-independent (standard DCB) 

@ Data communications 

e@ Device-dependent 


Figure 6-1 shows a generalized DCB and how its three _ sections 
relate to each other. 
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STANDARD DCB 
DEVICE- INDEPENDENT 
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Figure 6-1 DCB Sections 


The device-independent portion, also called the basic DCB, is 
identical to the standard OS/32 DCB. Figure 6-2 shows the fields 
of the basic DCB. 


The data communications-related portion of the DCB, immediately 
following the basic DCB, has fields pertaining only to devices 
requiring basic data communications support. Figure 6-3 shows 
the data communications-related portion of the DCB. 


The device-dependent portion of the DCB, immediately following 
the data communications-related portion, is used only if 
Gevice-dependent access is requested. This section contains 
fields unique to individual] lines or devices (e.g., asynchronous 
devices, binary synchronous lines and ZDLC lines). 


All references to the DCB fields must use the names specified in 
Figures 6-2 and 6-3. These names come from the OS/32 and Basic 
Data Communications Internal Macro and Structure Library supplied 
in the standard software package. 
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6.3.1.1 Device Control Block (DCB) Device-Independent Portion 
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1 
1 


(Standard DCB) 


DCB .TOUT 
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DCB .DCOP 
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DCB .RTRY 


Figure 6-2 Basic DCB Fields 
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Figure 6-2 Basic DCB Fields (Continued) 
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Figure 6-2 Basic DCB Fields (Continued) 
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Fields: 


DCB . LEAF is the fuliword address of the event 
coordination table entry for the _ physical 
devices described by the DCB. 


DCB.INIT is the fullword starting address of the SVCL 
Griver/terminal manager code. This address 
corresponds to the INITxxxx label in the 
Griver/terminal manager module itself. 


DCB . TERM is the fullword address of the Griver 
termination routine scheduled as the final ESR 
at end of command processing. 


DCB.IOH is the fullword list address of the IOH 
routines. The SVCl executor vectors from this 
IOH list to the specific routine for the 


requested function. IOH lists exist for 
asynchronous devices (IOHXASY) , binary 
synchronous devices (IOHMBSC), ZBID devices 
( IOHCZBD) and SVC15 accessed devices 
(IOHSVCF ). 

DCB . DONE is the fullword address of a special routine 


that does special device-dependent functions 
at I/O completion before branching to the 
standard IQDONE routine. 


DCB.ESR is the fullword address of the next driver 
entry point. At system queue service (SQS) 
time, event servicing begins here. Normally, 


this address is for the ISSEXEC routine. 


6.3.1.2 Device Control Blocks (DCB) Data Communications-Related 
Portion 


The data communications DCB contains fields pertaining to the 
devices requiring data communications support. All the fields 
within this part of the DCB are described in this” section. 
Figure 6-3 shows the format of the data communications portion of 
the DCB. 
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1204 (CC) | 206 (CE) 

DCB.RDN DCB .WDN 

! t 

SE see al Ss et ee ee te 
| 208 (DO) 

DCB.XITO 

! 
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|212(D4) {214 (D6) 

DCB. XDCD | DCB.LNST 
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{216 (D8) {218(DA) {| 219(DB) 

| DCB.ISTA | DCB.EXST | DCB.DVST 
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DCB. ITV DCB .OTV 
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eee TRON Veena ee OnE en am earn ee 
|244(F4) |246(F6) |247(F7) 
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| DCB . CHNB 
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DCB .MOCW 
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Figure 6-3 Data Communications DCB Fields (Continued) 
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Figure 6-3 


Fields: 


DCB.RCCB 


DCB .WCCB 


Data Communications DCB Fields (Continued) 


is the halfword with the address of the read 
CCB. 


is the halfword with the address of the write 
CCB. 


NOTE 


The auto driver channel requires 
CCBs to hold buffer pointers) and 
other information required during 
interrupt service routines (ISRs). 
Data communications require the 
read CCB and the write CCB to 
process read-after-write (RAW) . 
A simplex device can have only one 
CCB and can specify zero for the 
unused one. 
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DCB.LLR 
DCB. LLW 


DCB .FLCB 


DCB.CTCB 


DCB .TCCB 
DCB . HALT 


DCB .LSN 
DCB.TO1 
DCB .TO2 
DCB.CPCR 
DCB.CPTR 


DCB .BTRP 


DCB .DCW 


DCB .NDA 
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Devices geared to human response 
time can also use a single CCB for 
reads and writes. The use of one 
CCB saves some system memory, but 
also inhibits the RAW lookahead, 
possibly slowing read response 
time. (See below for further 
information on CCBs.) 


is the driver-maintained halfword to specify 
the length of last read. 


is the driver-maintained halfword to specify 
the length of last write. 


is the fullword address of a pointer to the 
beginning of an LCB chain used by file manager 
routines GETFCB and RELEFCB. This entry point 
must be in the same position as DCB.FCB within 
the file manager DCB. 


is the fullword address of the TCB for _ the 
currently executing task. The TCB selects I/O 
requests on behalf of the task. 


is the halfword address of the timer CCB. 


is the halfword address of a special halt 
routine (pure code) called by some drivers. 


is the logical segment number for an address 
check. 


is time-out 1 (screen time). 
is time-out 2 (OP response limit). 


is the fullword address for a channel program 
continuation return, referred to for line 
driver/terminal manager interface. 


is the fullword address for a channel program 
termination return, referred to for line 
driver/terminal manager interface. 


is the fullword address of the pointer to a 
continuous read buffer trap, referred to for 
line driver/terminal manager interface. 


is the fullword address of the relocated 
driver command words (DCWs). 


is the fullword address of the relocated next 
data area. 


DCB.CTA 


DCB .RDN 
DCB .WDN 


Both DCB.RDN 
and DCB.WDN 


DCB.XITO 


DCB .XDCD 


DCB.LNST 


is the fullword address of the command table 
within the particular driver. Every driver 
has a command table with addresses of routines 
that execute specific DCW commands. When the 
task issues an SVC15 request to the driver, 
the command field in the DCW serves as an 
index to one of these driver routines. 


Drivers can support different subsets of the 
standard set of driver commands. One command 
table might have some driver commands’ in 
common with other drivers while having other 
commands unique to itself. The command table 
must be coded as a DAC label. The label must 
be declared an EXTRN. 


is the halfword with the read device number. 
is the halfword with the write device number. 


are adjusted at assign time based on the 
actual system generated (sysgened) device 
number (DCB.DN) and the type of line indicated 
in the DCB.XDCD field (i.e., 2-wire or 4-wire, 
simplex, etc.). 


is the fullword with the SVCl extended data 
communications options obtained from the user 
parameter block. 


is the halfword for the extended device code. 
To use file manager routines, the entry must 
be at the same offset in the DCB as LCB.XDCD 
is within the LCB. DCB.XDCD must be generated 
as DC 2Z(xXDCD). XDCD must be declared an 
EXTRN. 


is the halfword for the line activity status 
used by line drivers and terminal managers. 
Table 6-1 describes the status bits for this 
halfword. DCB.LNST is structurally identical 
to LCB.LNST. 
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| HEX | 

| BIT | MASK |} NAME | MEAN ING 

| SSF SS SSEASISESRBPEEOX CGS SSL VRBSBASAIAISBPSVBSBSBOes SSF SE KSPesFs SSS SSSPSEBSPAZ2 LSPHPsrwe&sZs=s 2S 2B se222s22=2 
; O ; 8000 {| LNS.BSYM/B } DCB is being used. 

H eee es cae sane em cate ec mee OSD ne mame Om UTD GD GD nash hm came ms nem ee ween ee i tae re we ee cee me cree cee came ee ee ee en ee ee ee 
' 1 {| 4000 {| LNS.RWM/B ;} Line is currently performing a read. 

\ a a a a ses meno ci “a i ek i eae es emmy Ness Sc cl fesse Vt eer snes eae wie es eve esa a eels eas 
i; 2 {| 2000 |; LNS.INTM/B | Line is currently with a read or write 

H aneea ton phase. 

H a aa a a a ym a a a a a a ag ge cae sa me ce eV es an "asl os ges en ease mma ce mem ae 
; 3 |} 1000 {| LNS.ACKM/B ! Next ACK should be an ACK1. 

| a fe ne nha ee a ee lm a ee fe ape ens) hc ce Coase ms) fe i a fn cea sm sek ey ls me fe as ena es Sve Tae Paes ee me, em etc as Cs 
' 4 {| 0800 ; LNS.ACQM/B ; An ACK is required. 

} js a i a a a a i a a i ae ae a cs “aes ee a ak a i a ce ee fe es 
i; 5 {| 0400 | LNS.HLDM/B | Put any future [I/O requests into I/0 

H 1 | | wait. A DONE return to user task 

H 1 | CUE eesk) is pending. 

| ie na a ec ea ae a me Pa fa a a al a fc a a cl et ae ed ee ss as Se fe, ens ee ee 
i 6 {| 0200 ; LNS.IOM/B ;| I/O is currently in progress. 

H a i a a a a a i i a a a a an a a ae a ee i sae mt ee es a eds me 
i 7? {| 0100 {; LNS.RVIM/B ; Reverse interrupt received. 

{ en ei at a a hl nye ce Sh tm es es a a a a a se kal i a a ene ah i me eae cn ie 2 
i; 8 {| 0080 {| LNS.ERRM/B ; An Sutee angina unrecoverable error 

i ' { | ede 

H Ss a a ca a a a a a a ak a es a 
i; 9 {| 0040 | LNS.EOTM/B | End of transmission received. 


H 15 } | Reserved H 
DCB.ISTA is the halfword into which the line driver 
stores SVC15 status. 
DCB .EXST is the byte reserved for the driver. 
DCB .DVST is the byte for saving the latest device 
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TABLE 6-1 DCB.LNST BIT DEFINITIONS 


OO ee eee ee ee ee eee ee ee 


status after an interrupt. This field and the 
DCB.ISTA field are useful for debugging 


purposes. 


DCB.SVCF 


DCB.IFC 
DCB.NCE 


DCB .MLT 
DCB .SLT 


DCB.IFLG 


DCB.ITB 


DCB.ESR2 


DCB.ITV 
DCB .OTV 


DCB .MXEC 


DCB.QBCT 


DCB. CHAR 


is the fullword with a pointer to the line 


Griver initiation routine. This address is 
used by the SVC15 executor and the terminal 
manager to enter the driver. In the DCB 


coding, DCB.SVCF must be coded as DAC INITxxxx 
and this label must be declared an EXTRN. 


As for general-purpose drivers, the driver 
initiation routine pointer is the beginning 
address’ of the driver responsible for 


communicating with the attached adapter and | 


device. Entered in the event service state 
from the SVC15 executor, this routine assumes 
DCB.DCW and DCB.NDA are valid and usually 
starts execution of DCW commands. 


is the halfword containing the SVC15 function 
byte and other information bits for line 
drivers. 


is the halfword with which the line driver 
keeps track of the mumber of commands 
executed. 


is the byte containing the main line-type 


Gescriptor for ITFM, the file manager. 


is the byte containing the subline-type 
descriptor for ITFM. 


is the halfword for flags. 


is the fullword with bits to be used by 
ISSEXEC and ITSRABS when scheduling ESRs for 
buffer management and system support 
functions. 


is the fullword address of the second ESR. 

is the halfword with an error timer value in 
seconds for input (reads). The MODE time-out 
command can change this value. 

is the halfword with an error timer value in 
seconds for output (writes). The MODE 
time-out command can change this value. 


is the halfword with a value for the maximum 
number of allowable error retries. 


is the byte with the count of queued buffers 
in use. With this count, the line driver 
keeps track of queued buffers. 


is the byte for temporarily saving characters. 
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DCB .CHNB 


DCB .DOCR 


DCB . DOCW 


DCB .MOCR 


DCB .MOCW 


DCB .AOC 


DCB.DISC 


DCB .SCN1 
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is the fullword address of the first buffer in 
a chain. 


is the byte used by the driver to disable the 
adapter after completing each read request. 
DCB.DOCR is coded as DCB ‘hexadecimal value' 
to agree with the adapter. 


is the byte used by the driver to disable the 
adapter after completing each write request. 
DCB.DOCW is coded as DCB '‘'hexadecimal value' 
to agree with the adapter. 


is the byte used by the driver to enable 
interrupts and to place the adapter into read 
mode. DCB.MOCR is coded as DB X'value', with 
the value of the bits depending upon how the 
adapter is to be used. 

is the byte used by the driver to _ enable 
interrupts and to place the adapter into write 
mode. DCB .MOCW must be coded as DB X'value', 
with the value of the bits dependent upon how 
the adapter is to be used. 

is the byte used to load programmable adapters 
with required information. DCB.AOC is coded 
as DB X'values', where the values’) might 
reflect such programmable information as: 

e line speed, 

e character size, 

@e parity information, 

@ number of stop bits, 

@ SYNC character, 


e test function or local loop-back, and 


@e synchronization technique. 


is the byte used by the driver to disable 


interrupts and, for switched lines, to 
disconnect the line (i.e., to drop data 
terminal ready). DCB.DISC is coded as DC 
X'value'. If the read device number is zero, 


then this command is issued to the write 
device number. 


is the fullword for the SVC15 data chain area 
5 tee 


DCB .SCN2 is the fullword for the SVC15 data chain area 


2. 

DCB .SCN3 is the fullword for the SVC15 data chain area 
3. ; 

DCB .SCN4 is the fullword for the SVC15 data chain area 
4. 


Terminal managers may place values into these fullwords' to 
provide data buffering information (e.g., buffer BEGIN and END 
address or TO and FROM list addresses to the line driver). 
6.3.1.3 Device Control Block (DCB) Device-Dependent Portion 

In order to remain reentrant, all additional storage required by 
any terminal managers must be in additional DCB space set aside 
here or in extra memory obtained from system space. 

For a description of the device-dependent portion of the DCB, see 
the appropriate data communications manuals. 


6.3.2 Line Control Block (LCB) 


All buffered terminal managers use an LCB to provide required 
format pointers, line control and device-independent interfaces. 


An LCB is usually a copy of the appropriate DCB with additional 
space for data blocks. The LCB is obtained from dynamic system 
space. As shown in Figure 6-5, the LCB consists of three 
segments: 

@ Device-independent segment (basic LCB) 


@ Device-dependent segment 


@e Data block descriptor 


6.3.2.1 Line Control Block (LCB) Device-Independent Portion 
The device-independent portion of the LCB is pictured in Figure 


6-4. The device-independent portion of the LCB is structurally 
identical to the basic DCB of Figure 6-1. 
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| L.CB.DMT 
| ! 
Wee Cor pesteaa eos eke ak wanes Gow ek tad ee Ea a ee ee a i a Sy Gikit sos ake acts atic sc a Gea tease aca Mice he rh es ln 
} | 
}4(04) | 
LCB .LEAF ! 
| | 
| a acl il a aa at aa ae gid se a a Pans ah ae a a a oF oes oa thee natin Si eerie teens etieead aha ---!) 
18(08) ;}10(0A) 
LCB.WCNT LCB.RCNT 
| | | 
H Ss a ad ois sc aes “eas ees as ae es cr ed a ee ee Nn eS tt i he te ee eae ath Ee 2 Oa eG Pao eee ; 
112(0C) ! 
LCB.FLGS 
| | 
H ss Sass pci mis em fein eu esas) ee ming i an es ln er Ga sa las bach al bea nn aco st “eyelash eu dena ce te Ce ee eee oe ee ee, os 
116(10) ! 
LCB.1INC 
\ ia ei el ein es an i as a lems avo oin (Se em asa alae eS ce an cl a cakes Sw i Sack eae ae ian ce eee el ee Sees ere ease eae eas ! 
120(14) ! 
LCB.7INC 
| sd ot iin hm. na “cvs a ec ee alsa ys a as a a a et el cial pare eat eis ta EE ce al aa ae { 
124(18) 125(19) '26(1A) 
RESERVED ! L.CB.DCOD LCB.DN 
{ { ] | 
Ag ce eee el ! 
128(1C) |30(1E) 
LCB.ATRB LCB.RECL 
| t t 
ec re ete : 
'32(20) ! 
LCB.INIT 
| wana nnn nnn nn nnn nnn nnn nnn ne enn ! 
136(24) 
LCB.FUNC | 
| 
fe ee mee 
'40(28) 
LCB .TERM | 
H Sacco eas Se 0s es tek os ke a ee es i ee at eee ses SS ee ak Sk ine a eee tae a tien eta eral, ! 
'44(2C) '46(2E) ! 
LCB.TOUT LCB.RTRY 
| ( ! 
{ ! 1 
| i cr i in acs as a i ae a i a i a, ace ig a a ame sa ee eer weet | 
148(30) 149(31) 150(32) 
LCB.WKEY LCB.RKEY RESERVED 
H 
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Figure 6-4 Basic LCB Fields 
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Figure 6-4 Basic LCB Fields (Continued) 
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| LCB .UPBK 
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1108 (6C) 

LCB.PBLK 

t 

ern eee ee ere on are te eee me ee oe 
{112(70) {113(71) 1114(72) 1115(73) 

LCB.FC | LCB.LU | LCB.STAT | LCB.DDPS 

! | | 4 

fire eneta Be ee a eee z 
1116(74) 

LCB.SADR 

t 

eee ene Tes aE Oe See nee eat ee ane ee a ne oem eee 
1120(78) 

LCB.EADR 

' 

an nT ELS OE AOE ON ES eee eS eT OLE eR RE 
1124(7C) 

| LCB.FLRS 

{ 

a a ance a an ee eee eee ee 
1128(80) 

l LCB.LUE 
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{132(84) 

LCB.SV1X 
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1136 (88) 

| LCB .WCHN 

' 
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{140(8C) 

l LCB.SIZE 
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Figure 6-4 Basic LCB Fields (Continued) 
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ee me ee ee ee eee ee ee ee 


Fields: 


LCB.DMT 


LCB . LEAF 
LCB .WCNT 
LCB .RCNT 
LCB.FLGS 
LCB.1LINC 
LCB.7INC 
LCB .DCOD 


LCB .DN 


LCB.ATRB 
LCB.RECL 


LCB.INIT 
LCB.FUNC 
LCB.TERM 


LCB .TOUT 
LCB.RTRY 
LCB .WKEY 
LCB.RKEY 


LCB.FLRT 


LCB . TOCH 


LCB.XFLG 
LCB. 10H 


LCB.Q 


is the fullword address of the device mnemonic 
table (DMT) entry. 


is the fullword address of an event leaf. 

is the halfword for the write count. 

is the halfword for the read count. 

is the fullword for the flags. 

is the SVCl device intercept. 

is the SVC7 device intercept. 

is the byte for the device code (DCB number). 


is the halfword for the device number (a 
physical address). 


is the halfword for the device attributes. 
is the halfword for the record length. 


is the fullword address~- of the driver 
initiation routine. 


is the fullword address of the driver function 
routine. 


is the fullword address of the driver 
termination routine. 


is the halfword for the time-out constant. 

is the halfword for the operation retry count. 
is the halfword for the write key. 

is the halfword for the read key. 


is the fullword for the close/checkpoint' save 
area. 


is the fullword address of the time-out chain. 


is the halfword for the dev ice-dependent 
flags. 


is the fullword address of the IOH list. The 
default is zero. 


is the fullword address of the queue strategy 
routine. The default is zero. 
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LCB .EDMA 


LCB.NXT 


LCB.RFLG 


LCB.PRI 


LCB.TYPE 


LCB . DONE 


LCB.DCB 
LCB.TCB 


LCB.ESR 


LCB .UPBK 


LCB.PBLK 


LCB.FC 
LCB.LU 
LCB.STAT 
LCB.DDPS 


LCB.SADR 


LCB.EADR 


LCB.FLRS5 


LCB .LUE 


LCB.SV1X 
LCB .WCHN 
LCB .SIZE 


LCB.VFC 
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is the fullword address of the extended direct 
memory access (EDMA) strategy routine. 


is the fullword link to the next IOB. 


is the halfword for the request-dependent 
flags. 


is the byte for the I/0 priority. 
is the byte for the IOB-type code. 


is the fullword address of the IODONE 
executor. 


is the fullword address of the DCB. 
is the fullword address of the TCB. 


is the fullword address of the next entry into 
driver. 


is the fullword task-relative address of the 
SVC parameter block. 


is the fullword absolute address of the SVC 
parameter block. 


is the byte for the SVC function code. 

is the byte for the SVC logical unit (lu). 
is the byte for the I/O status. 

is the byte for the device-dependent status. 


is the fullword absolute starting address of 
the SVCl1 buffer. 


is the fullword absolute ending address of the 
SVCl buffer. 


is the fullword checkpoint save area for 
register 5. 


is the fullword LCB address used in the 
contiguous file manager. 


is the extended SVCl word. 
is the task waiting for this I/O to complete. 
is the size in sectors or lines. 


is the fullword address of VFCDCB. 


6.3.2.2 Line Control Block (LCB) Device-Dependent Portion 


The device-dependent portion of the LCB is pictured in Figure 
6-5. 
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| 160(A0) 
! Reserved | 
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a en ee ee ee ! 
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'168(A8) | 
LCB.BSB 
aa aa a a a a aa 
1172(AC) | 
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[SSH eea Sesh oSee a see Se Sa See Seen See eee ere ee 
1176(BO) 
LCB.URPB 
 fesiedateetentanenstentenienietanteectentestentasheshententesieententententedentaatenteahedecteatasteatamea eteatadeaiedetertententemearesteaienieteitereaan | 
'180(B4) 
LCB.RPB 
J en ce ee ee ee cm ae caer ee 
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Figure 6-5 Device-Dependent LCB Fields 
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Figure 6-5 Device-Dependent LCB Fields (Continued) 
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—_— 


It should be noted that the device-dependent portion of the LCB 
described in this section may vary in structure for different 


terminal managers. 


Fields: 


LCB .NAME 
LCB.EXT 


LCB.LCB 


LCB.BSB 


LCB .BSE 


LCB.URPB 


LCB.RPB 


LCB.SV1B 


LCB.DCW 


LCB.NDA 


LCB .WKBF 


LCB .BKSZ 


LCB . BKRK 


LCB.BKCT 


LCB.GDCT 


LCB.LSTE 


LCB.XITO 


LCB.XDCD 


is the doubleword for the filename. 
is the fullword for the extension. 


is the fullword LCB-to-LCB linkage address for 
SVC7. 


is the fullword absolute starting address’ of 
the segment (the buffer segment begin 
address). 


is the fullword absolute ending address of the 
segment (the buffer segment end address). 


is the fullword task-relative address of the 
SVC parameter block. 


is the fullword absolute address of the Svc 
parameter block. 


is the fullword address of the SVCl buffer for 
delays. 


is the fullword for storage of the DCW address’ 
for retries. 


is the fullword for storage of the next data 
area (NDA) address for retries. 


is the halfword address of the work buffer to 
receive ACK. 


is the halfword for the size of each data 
buffer. 


is the byte for the maximum records permitted 
in each block. 


is the byte for the total number of data 
blocks assigned. 


is the byte for the good transmission counter. 


is the byte for the error code of the last 
transmission. 


is the fullword for the extended options. 


is the halfword for the extended device code. 
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LCB.LNST 


LCB.HTMP 


LCB.SCN1L 
LCB.SCN2 
LCB.SCN3 


LCB.SCN4 


is the halfword for the line activity status. 


are the nine halfwords for the horizontal tab 
bit map. 


is the fullword for data area l. 
is the fullword for data area 2. 
is the fullword for data area 3. 


is the fullword for data area 4. 


6.3.2.3 Line Control Block (LCB) Data Block Descriptor Portion 


The data block descriptor described in this section is an LCB 
subtable that controls the use of individual internal buffers. 


BLK .RKCT 


BLK .ADR 


BLK.PTR 


BLK.DSCR 


is the byte for the count of records in the 
block. 


is the address of the data block. 


is the halfword for relative offset into a 
Gata block. 


is the halfword for the data block descriptor 
flags. See Table 6-2. 


TABLE 6-2 BLOCK DESCRIPTOR FLAG BIT DEFINITIONS 


H | HEX 
| BIT | MASK 
|aacmesiceses 
; O |; 8000 
tes, 

i) 

; 12 4 4000 
H H 

! 

r+ 2  { 2060 
{ H 

H 

| 3 { 1000 
H 

H 

H 4 ; 0800 
i H 

I 

| 5 ; 0460 
i] 

t 

| 6 | 0200 
{ 

! 

1 8 ; 0080 
i] 

9 i} 0040 


BLK.QUM/B ; Line buffer is on queue for either an 
i} 
t 


J 
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-BSM/B | Line buffer is currently being used. H 


LK.RWM/B | Line buffer is currently being used 
! 
1 


1 
{ 
for a read. : 
i] 
i] 


BLK.BKM/B ; Line buffer blocking or deblocking is |} 
{ ! 
4 I 


currently in progress. 


(ee wees eee in fae ee es em comt ems etm ewe me em teee rm ee me De in es es ee es 


‘ 

{ 

BLK.IOM/B ; Line buffer is currently being used ] 
t i 

3 ! 


for I/O. 
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output write or input deblocking. 
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6.3.3 Channel Control Block (CCB) 


The CCB contains the 
halfwords used by the line drivers and the clock halfword. 


address of the DCB, 


the 


fullwords and 


6.3.3.1 Channel Control Block (CCB) Device-Independent Portion 


This section discusses the device-independent (sta 
The device-independent CCB format is illustrated in 


of the CCB. 
Figure 6-6. 


ndard) fields 
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Figure 6-6 


CCB Device-Independent Portion 


48-077 FOO ROO 


Fields: 


CCB .CCW 


CCB .LBO 


CCB .EBO 


CCB .CW 


CCB.LB1 


CCB.EB1L 


CCB.XLT 


CCB .SUBA 


CCB.MISC 


CCB.FLGS 


CCB .DCB 


CCB .XLT2 


is the halfword containing the channel command 
word (CCW). 


is the halfword containing the length of 
buffer 0. 


is the fullword containing the end address of 
buffer 0. 


is the 16-bit check "word". 


is the halfword containing the length of 
buffer 1. 


is the fullword containing the end address of 
buffer 1. 


is the fullword containing the address of the 
translation table. 


is the halfword address of the subroutine 
(pure code). 


is the l-byte temporary save area used by line 
drivers. 


is the l-byte for CCB flags. 


is the fullword containing the address of the 
associated DCB. 


is the fullword address of the secondary 
translation table. 


6.3.3.2 Channel Control Block (CCB) Device-Dependent Portion 


This section discusses the fields of the CCB used by data 


communications. 
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The CCB format is illustrated in Figure 6-7. 
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Figure 6-7 Data Communications CCB Format 
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Fields: 


CCB. 


CCB. 


CCB. 


CCB. 


CCB. 


CCB. 


CCB. 


CCB. 


CCB. 


CCB 


CCB. 


CCB 


CCB 


CCB. 


CCB. 


BFO 


SAV1 


SAV2 


BF 1 


CMD 


RECS 


TLXF 


BMOD 


ITIM 


- DN 


PITC/ 


-NITC 


.QBF 


QBT 


PDCT 
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is the fullword used by the line driver during 
ISRs containing the beginning address of 
buffer zero. 


is the halfword save area l. 
is the halfword save area 2. 


is the fullword used by the line driver during 
ISRs containing the beginning address of 
buffer 1. 


is the halfword storage for the DCW. 


is the halfword used by the binary synchronous 
driver to contain CCB count equivalent to 
transparent record size. 


is the halfword used to total the length of 
transfers when using chained buffers. 


is the halfword required by drivers that must 
maintain their present mode; i.e., binary 
synchronous and future asynchronous drivers. 


is the halfword used by the clock. 


is the halfword used by the clock containing 
a device number correspondng to the CCB (read 
or write). [t is initialized by the file 
manager at assign time. 


are the halfwords used by the clock containing 
previous and next pointers of the forward- and 
backward-linked time chain. It must be coded 
as DC H'0O',H'O'. 


is the address of a queued buffer from the 
list (queued buffer support, lines only). 


is the address of a queued buffer to the list 
(queued buffer support, lines only). 


is the halfword pad count used by the direct 
I/O subsystem (DIOS). The relative position 
of this field in the CCB is fixed. 


6.3.4 Drop Control Table (DCT) for Zero-Bit Insertion/Deletion 
Data Link Control (ZDLC) Communications 


The DCT is a system table that is either allocated by the user or 
sysgened into the DCB. The DCT stores data necessary for 
controlling ZDLC communications with a specific drop. Included 
with its data are the relocated addresses (i.e., addresses 
relocated from task space to system space) of the: 


e four circular lists (for the u-task I/O buffers), 

@ secondary station address (SSA) of the allocated drop, and 

e logical filename.ext of the drop. 

When directed by the SVCl extended option bits, these parameters 


are placed into the DCT from the user's DDT. Figure 6-8 depicts 
the DCT. 
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Figure 6-8 DCT (ZDLC) Format 
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Figure 6-8 DCT (ZDLC) Format (Continued) 
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is the fullword pointing to the address of the 
next DCT on the chain of DCTs. 


| 
| 
136(24 
140(28) 141(29) 
DCT . HOLE 
144(2C) 
DCT.SDS 
_ 
148 (30) 
DCT.MBFS 
$ 
: 
152(34) 
DCT.ORFC 
! 
: 
156(38) 57(39) 
{|  DCT.OCR 
! 
: 
160(3C) 161(3D) 
{ DCT.INEF | 
| 
| 
164(40) 65(41) 
DCT. IOSR 
! 
: 
168 (44) ! 
{ DCT.OCNT | 
Fields: 
DCT .LINK 
DCT .SSA 


is the first byte for the SSA. 


DCT.SSAL 


DCT. FNM 


DCT .UDR 


DCT . UQW 


DCT . UDW 


DCT.IDR 


DCT. IDW 


DCT . HOLE 


DCT . HLNK 


DCT.SDS 
DCT .DDS 
DCT .MBFS 


DCT .MNOF 


is the 3-byte link to any additional SSA 
bytes. 


is the 12-byte field containing the 1l-byte 
filename.ext (logical drop name) for the DCT; 
the last byte is unused. 


is the fullword pointing to the user done with 
read (UDR) circular list (the read-done list) 
associated with the drop. 


is the fullword pointing to the user queue for 
write (UQW) circular list (the write list) 
associated with the drop. 


is the fullword pointing to the user done with 
write (UDW) circular list (the write-done 
list) associated with the drop. 


is the fullword header pointing to the 
internal read-done chain of input frames. It 
is not yet passed to the UDR circular list. 


is the fullword header pointing to the 
internal write-done chain of output frames 
that has already been transmitted, but is 
awaiting acknowledgement. 


is the l-byte "frame hole" indicator having a 
value of X'FF', when applicable. When not 
used, this byte is reset to zeros. (A hole is 
a missing I-frame within the _ input data 
register (IDR) chain. The frame was 
selectively rejected by the channel terminal 
manager (CTM) and, consequently, not entered 
into the IDR chain.) 


is the 3-byte link to the address of the next 
frame after the hole in the IDR chain. When 
not used, these bytes are reset to zeros. 


is the halfword static drop status describing 
drop criteria to the CTM. 


is the halfword dynamic drop status reflecting 
drop activity at the given time. 


is the halfword containing the maximum size of 
a frame that can be transmitted for the drop. 


is the byte containing the maximum number of 


frames on the internal write-done (IDW) chain 
that can be awaiting acknowledgement. 
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DCT .ORRC 


DCT .ORFC 


DCT . NOAB 


DCT.TPER 


DCT.OCR 


DCT .OCX 


DCT .PPD 


DCT.PSC 


DCT. INEF 


DCT.ILFA 


DCT.INFA 


DCT. INUF 


DCT.IOSR . 
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is the byte containing the rejection reason 
code for an FRMR frame (i.e., a UN-frame 
having a FRMR code in the control field 
(C-~field) being output. 


is the halfword containing the rejected 
C-field to be included within the FRMR frame 
being output. 


is the byte specifying the number of address 
bytes in the SSA. 


is the byte containing the reason code of the 
problem-causing trap. 


is the byte containing the binary index code 
of the NUMBERED or UNNUMBERED C-field sequence 
to be output. 


is the byte into which the command code 
requested by the above DCT.OCR is stored 
before the appropriate N- or UN-frame is 
output. 


is the byte determining the poll priority of 
the drop. 


is a byte used to defer an implied rejection. 
(An implied rejection occurs when a drop 
receives an N- or I-frame having the P/F bit 
set and the N(R) value less than the sequence 
number, N(S), of the next frame to be 


transmitted. ) 


is the byte indicating the next expected 
sequence number, N(S), of an incoming I-frame. 


is the byte indicating the sequence number, 
N(S), of the last input I-frame that was 
acknowledged. 


is the byte indicating the sequence number, 
N(S), of the next expected input I-frame to be 
acknowledged. 


is the byte indicating the sequence number, 
N(S), of the next input I[I-frame that can be 
passed from the IDR chain to the UDR list. 


is the byte containing the sequence number, 
N(S), of a selectively rejected input I-frame 
that is currently outstanding. 


DCT .ONTX © is the byte indicating the sequence number, 
N(S), of the next I-frame to be transmitted. 


DCT .OLRR is the byte containing the sequence number, 
N(R), of the last RR (receive ready) frame 
received from another drop. 


DCT .ONRT is the byte containing the sequence number, 
N(S), of the next output I-frame needing 
retransmission; this I-frame must be in the 
IDW chain. 7 


DCT.OCNT l-byte counter for I-frames transmitted or 
received in response to a poll. 


To communicate with a drop, a DCT for that drop must be in system 
space. The DCT gets into system space in one of two ways: 


1. The user allocates the DCT with an SVC7 call based on an 
extended SVC7 parameter block. Issuing the SVC7 call does 
the following: 


e Allocates a DCT from system space. 


e Enters the logical filename.ext and SSA from the SVC7 
parameter block into the DCT. 


e Initializes DCT control fields to specific values needed 
by the CTM. 


2. As a user convenience, static DCTs can be sysgened as 
permanent tables within the DCB; the user need not allocate 
the DCTs. At sysgen, the DCB for the ZDLC line can have one 
or more DCTs built in with each DCT having a defined logical 
filename.ext and secondary station address. To communicate 
with a drop defined this way, the user must know the logical 
filename.ext of the drop. 


6.3.5 Drop Definition Table (DDT) for Zero-Bit Insertion/ 
Deletion Data Link Control (ZDLC) Communications 
The DDT is a table the user sets up in task space as an extension 


to the SVCl parameter block. It supplies additional parameters 
needed for ZDLC protocol support, including: 


@e the logical name of the drop with which ZDLC communications 
are wanted, and 


e the addresses of the four circular lists (read pool, read-done 
list, write list, and write-done list) needed for I/O. 
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When the user issues the SVCl call, DDT parameters are passed to 
the DCT and the DCB. 


As defined for ZDLC protocol, a drop is a logical starting or 
ending point on a ZDLC communications line. A drop can be a 
primary station, a secondary station, or a station acting as 
multiple secondaries. Figure 6-9 depicts the DDT. 
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Figure 6-9 DDT (ZDLC) Format 


Fields: 


DDT.SSA used when a user changes the secondary station 
address of a drop. Holds the replacement SSA. 
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DDT .SSAL holds pointer to additional SSA bytes when a 
u-task changes an SSA to have more than one. 
byte. 


As seen in Figure 6-9, the first byte of this 
fullword is an additional SSA byte and the 
following three bytes point to another SSA 
byte, if necessary. The last SSA byte has its 
pointer filled set to zero. 


DDT . FNM defines the logical drop name and extension 

DDT. EXT by which the drop is known to the system. 

DDT .UQR is the address of the UQR list (user's” read 
pool). 

DDT .UDR is the address of the UDR list (user's 
read-done list). 

DDT . UQW is the address of the UQW list (user's write 
list). 

DDT . UDW is the address of the UDW list (user's 


write-done list). 
6.3.6 Drop Control Table (DCT) for Asynchronous Multidrop. 
Communications 

The DCT for asynchronous multidrop communications is a caps 
system table that is allocated by the user executing the generate 
macro or command. One DCT per terminal is allocated to specify 
the drop. Fields in the DCB specific to asynchronous multidrop 
communications contain the DCT queue control data. The following 
are included with the DCTs: 

@e Logical filename/extension of the drop 


@ Device access queue control data 


@e Line polling/selection address of the drop 


The structure of the DCT is shown in Figure 6-10. 
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Figure 6-10 DCT (Asynchronous Multidrop) Format 
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Fields: 


DCT . DLNK is the link to the next DCT (from the DCB). 

DCT. NAME is the file descriptor (fd) for the particular 
terminal. 

DCT.FDAT is the first DAT used by this DCT. 

DCT.LDAT is the last DAT used by this DCT. 

DCT .DFQH is the first DAT on the function queue chain. 

DCT.DFQT is the last DAT on the function queue chain. 

DCT .DQLK is the link to the next DCT in the function 
queue chain. 

DCT .DCB is the pointer to the parent DCB. 

DCT.FLGS is a halfword reserved for flags. 

DCT .LADR is the polling/selection line address for the 
particular terminal. 

DCT .WCNT is the halfword for the write count. 

DCT .RCNT is the halfword for the read count. 


6.3.7 Drop Access Table (DAT) for Asynchronous Multidrop 
Communications 


The DAT is a system table that is internally allocated when an lu 
is assigned to a terminal. The following are included with its 
Gata: 
e lu 


@e I0B queue control data 


e Timer chain data 


The structure of the DAT is shown in Figure 6-11. 
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Figure 6-11 DAT (Asynchronous Multidrop) Format 

Fields: 

DAT . DLNK is the link to the next DAT for the current 
DCT. 

DAT . FOLK is the link to the next DAT in the _ function 
queue chain. 
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DAT . TMLK is the link for the timer chain. 


DAT. LU is the byte for the lu assigned to the DAT. 

DAT .TCB is the address of the. 

DAT .DCT is the address of the parent DCT of this DAT. 

DAT .DCB is the address of the parent DCB of this DAT. 

DAT. IOBH is the pointer to the first IOB for this DAT. 

DAT.TIMR is the timer value. 

DAT. FLGS is a halfword reserved for flags. 

DAT. IOBT is a pointer to the last IOB for this DAT. 

DAT .APRV is the access privilege byte. 

DAT .CONB is the multi-terminal monitor (MTM) TCB' save 
area. 


6.3.8 Input/Output Block (I0B) for Asynchronous Multidrop 
Communications 


The [0B is allocated from system space and chained to the TCB. 
This occurs both at load time and assignment time. At load time, 
the number of IOBs built is dependent on the Link option IOBLOCK. 
If the option is not specified, a default of one IOB is contained 
in the _ TCB. At assignment time, additional IOBs are allocated 
and chained, thereby eliminating the problem of proceed I/O 
waiting for a free I/O block. The IOB contains I/O information 
that includes the SVCl parameter block. The structure of the IOB 
is shown in Figure 6-12. 
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Figure 6-12 I0B Format 
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Figure 6-12 


IOB Format (Continued) 


Fields: 


[OB .NXT 
I[OB.RFLG 
IOB.PRT 
[OB .TYPE 
[OB . DONE 
IOB.DCB 
IOB.TCB 
IOB.ESR 
IOB.UPBK 
[OB . PBLK 
IOB.FC 
[TOB.LU 


[0B.STAT 


[OB .DDPS 


[OB.SADR 
IOB .EADR 


TOB. RAND 


[OB .LUE 
IOB.SV1LX 


[OB .WCHN 


TOB. CYT 
10B.SECT 


IOB.LSEC 


is a fullword that holds the forward pointer. 
is the request-dependent flag. 

is the I/O priority. 

is the type byte. 

is the address of the I[ODONE/SUB executor. 
is the address of the parent DCB. 

is the pointer to the caller TCB. 

is the driver entry fullword. 

is the unrelocated parameter block address. 
is the relocated parameter block address. 
is the SVCl function code. 

is the SVCl I/O lu number. 


is the device-independent status from the SVC1l 
parameter block. 


is the device-dependent status from the SVCL 


parameter block. 
is the buffer start address. 
is the buffer ending address. 


is the positional address of the logical 
record to be accessed for a data transfer. 


is the lu entry address. 
is the extended SVCl word. 


is the list of tasks waiting for the current 


I/O to finish. 
is the requested cylinder *2 for a disk. 
is the starting relative sector. 


is the relative position of the last sector. 
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6.3.9 Station Description Table (SDT) for 3270 Emulator 


The SDT is attached to the DCB and is created from system space, 
one per control unit, when the GENERATE command is executed. The 
following are included with its data: 


e Control units polling/selection addresses 


e Pointers to the DDTs for the devices on the control unit 


The structure of the SDT is shown in Figure 6-13. 
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Figure 6-13 SDT Format 
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Fields: 


SDT.LINK is the link to the next SDT. 

SDT .DDT is the link to the first DDT on the station. 
SDT .LDDT is the link to the last DDT on the station. 
SDT.DCB is the link to the parent DCB. | 

SDT .CUP is the station control unit polling address. 
SDT.CUS is the station control unit selection address. 
SDT .STAT is the status of the control unit. 

SDT.TS is the general polling time stamp. 


6.3.10 Device Definition Table (DDT) for the 3270 Emulator 


The DDT is a system table that is attached to the SDT. DDTs_ are 
created at generation time from system space and one DDT is 
created for each device to be generated. Each DDT is chained to 
the proper SDT according to which control unit the device is to 
be attached. The following are included with its data: 


@ Device address for the virtual terminal for which it is 
generated 


e Pointer to the screen image storage (SIS) buffer 


The structure of the DDT for the 3270 emulator is shown in Figure 
6-14. 
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Figure 6-14 DDT (3270 Emulator) Format 
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Figure 6-14 DDT (3270 Emulator) Format (Continued) 


LINK. 


SSA 


. TYPE 


- TOC 


-RSTA 


is 


is 


is 


is 


is 


the 


the 


the 


the 


the 


link to the next DDT. 
secondary station address. 
3270 device type. 

[/O request counter. 


last reported device status. 
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DDT.STAT is the 3270 device status. 


DDT. IOB is the address of the retained IOB. 

DDT .WRQT is the pointer to the top of the write ready 
queue. 

DDT .WRQB is the pointer to the bottom of the write 
ready queue. 

DDT .RDOQT is the pointer to the top of the read done 
queue. 

DDT . RDQB is the pointer to the bottom of the read done 
queue. 

DDT.SIS is the address of the screen image storage. 

DDT.SDT is the address of the station descriptor 
table. 

DDT . LU is the assigned lu. 

DDT .TOB is the address of the connector TOB. 

DDT .FEPL is the format terminal manager (FTM) entry 
from the protocol terminal manager (PTM) link. 

DDT. FEVL is the FTM entry from the virtual terminal 
monitor (VTM) link. 

DDT. TIMI. is the logical I/O timer link. 

DDT .DSTA is the dynamic status halfword. 

DDT .FLGS is a halfword reserved for control flags. 

DDT . LXF is the length of data transfer. 

DDT . NAME is the virtual terminal name. 

DDT . BCNT is the write queue buffer counter. 

DDT.FSTA is the FT status field. 

DDT.TIMR is the current logical timer value. 

DDT.TS is the general polling time stamp. 


6.3.11 Input/Output Handler (IOH) 
The IOH is a system structure that handles I/O from the 08/32 


SVCl parameter block. The structure of the IOH is shown in 
Figure 6-15. 
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IOH Format 


Figure 6-15 
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Fields: 


[OH . READ 


IOH.WRIT 


IOH.WAIT 


ITOH. HALT 


IOH. TEST 


IOH. SET 
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Figure 6-15 IOH Format (Continued) 


is the fullword address of the SVCl_ read 
executor. 


is the fullword address of the SVCl write 
executor. 


is the fullword address of the SVCl wait-only 
executor. 


is the fullword address of the SVCl halt I/0 
executor. 


is the fullword address of the SVCl test I/O 
completion executor. 


is the fullword address of the SVCl test and 
set executor. 


IOH. REW is the fullword address of the SVCl_ rewind 
executor. 

IOH.BSR is the fullword address of the SVCl backspace 

record executor. 

IOH.FSR is the fullword address of the SVCl forward 
space record executor. 

IOH.WFM is the fullword address of the SVCl write file 
mark executor. . 

IOH.FFM is the fullword address of the SVCl_ forward 
file mark executor. 

IOH.BFM is the fullword address of the SVCl backspace 
file mark executor. 

IOH.EOT is the fullword address of the SVC task 
termination executor. 

IOH. INIT is the fullword address of the device 
initialization routine. This routine is 
entered when the operating system is first 
started. 

IOH.DDF is the fullword address of the 
device-dependent function executor. 

IOH.CON is the fullword address of special entry for 
the operating system console. 

IOH. PWR is the fullword address of the power’. restore 
initialization routine. This routine is 
entered after a power restoration. 

6.3.12 File Manager Handler (FMH) 

The FMH is a system structure that handles SVC7 functions for 
data communications. The format of the FMH is shown in Figure 
6-16. 
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Figure 6-16 FMH Format 
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Fields: 


FMH . ALL is the fullword address of the SVC7 allocate 
routine. 

FMH . DEL is the fullword address of the SVC7 delete 
routine. 

FMH.OPN1 is the fullword address of the standard SVC7 


assign routine. 


FMH .OPN2 is the fullword address of an optional SVC7 
assign routine, which can be used by buffered 
terminal managers for additional processing, 
after FMH.OPN1 branches to the operating 
system for common processing. 


FMH . CKPT is the fullword address of the SVC7 checkpoint 
routine. 

FMH.FTCH is the fullword address of the SVC7_ fetch 
attributes routine. 

FMH .CLOS is the fullword address of the SVC7 close 
routine. 

FMH . RSLU is the fullword address of the SVC6 1lu/TCB 
exchange lu routine. 

FMH . CAP is the fullword address of the SVC7 change 
access privileges routine. 

FMH .REN is the fullword address of the SVC7 rename 
routine. 

FMH . REP is the fullword address of the SVC7 reprotect 
routine. 


6.4 DEVICE CONTROL BLOCK (DCB) POINTERS FOR LINE DRIVER COMMAND 
INTERPRETATION 


Sysgen includes one DCB for each adapter (line) configured in the 
system. The DCB contains information about that line, its modem, 
and sometimes, the attached terminals. Line driver command 
interpretation is controlled by pointers contained in the DCB. 
These pointers are the: 


e Driver initiation routine DCB.SVCF 
@e Command table used for decoding commands DCB.CTA 
e Translation tables available for this device DCB.XLT 
e Driver command termination routine | DCB .TERM 
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e Actual output commands required by the adapter DCB.DOCR 


DCB . DOCW 
DCB .MOCR 
DCB.DISC 
@ Programmable adapter information DCB . AOC 
@e SVC1l terminal manager entry (if supported) DCB.INIT 
e Adapter device numbers DCB.RDN 
DCW.WDN 
@e Error timeout values DCB.ITV 
DCB.OTV 
@e Next entry into the driver (ESR scheduling) DCB.ESR 
@ CCB required for the DCB.RCCB 
adapter DCB .WCCB 


6.4.1 DCB.TERM Pointer 


When a driver schedules its own ESR, it branches to an address 
pointed to by the driver termination code which usually checks to 
see if the command is chained. If the command is chained, it 
continues with command fetching or it terminates the entire SVC15 
request by branching to CMTERM, the data communications 
equivalent of IODONE. 


6.4.2 DCB.DOCR, DCB.DOCW, DCB.MOCR and DCB.MOCW Pointers 


A single type of adapter, a programmable asynchronous” line 
adapter (PASLA) for example, may require different commands to 
control it, depending on how it is strapped and how it is to be 
used (i.e., half-duplex, full-duplex, echoplex or reverse 
channel). The DCB has space to hold the actual bytes used for 
the output commands. A single driver can therefore issue the 
proper output command to several differently strapped adapters. 


DCB .DOCR is the command used to disable an adapter 
leaving the read mode. 


DCB . DOCW is the command used to disable an adapter 
leaving the write mode. 


DCB .MOCR is the command used to enable an adapter and 
place it into read mode, assuming a previously 
unknown state. 


DCB .MOCW is the command used to enable an adapter and 


place it into the write mode, assuming a 
previously unknown state. 
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6.4.3 DCB.AOC Pointer 


This byte is used to pass required information (such as mode, 
parity, line speed, number of stop bits, etc.) to a programmable 
adapter. It is generally the CMD2 byte. This allows one driver 
to communicate with various similar terminals operating at 
different speeds. 


6.4.4 DCB.INIT Pointer 


Terminals supported for SVCl access must have a pointer to the 
beginning of the terminal manager code for the attached terminal. 
This is provided in the DCB. The label referenced by DCB.INIT is 
of the form INITxxxx and is declared an EXTRN in the DCB. 


6.4.5 DCB.RDN and DCB.WDN Pointers 


Communication adapters can have one or two device numbers, again 
depending on the strapping. A 2-wire (half-duplex) adapter uses 
the same device number for both reading and writing, while a 
4-wire (full-duplex) adapter uses two different numbers. Drivers 
can remain transparent to this difference by using the numbers 
supplied in the DCB when needed. 


A simplex device has only one of these numbers (the other is 
zero, signifying no device). 


These numbers are set up at assign time by ITFM, which uses 
DCB.DN and DCB.XDCD, both initialized at sysgen. The real device 
number should be specified at sysgen time. 


6.4.6 DCB.ITV and DCB.OTV Pointers 


The time values used to abort an [/O if not completed within the 
allotted time period are obtained from the DCB. There are two 
halfwords, one for read and one for. write. Thus, similar 
devices can have time-outs that vary depending on the intended 
use of the line and the attached device. These time values are 
in 1l-second increments with a resolution of +0, -1 second. 


6.5 EVENT SERVICE ROUTINE (ESR) SCHEDULING 


Execution of data communications line a@river code can overlap 
execution of certain buffer management routines that execute in 
ES(NSU) state, except for actual I/O processing. For I/O 
processing, these routines execute in the IS state. Therefore, 
ESR scheduling is required because concurrent events might result 
from overlapped processing. 
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Examples of concurrent events are: 


@e 1l-second error timer time-out 
@e 100ms timer time-out 
@e System console cancellation of a task 


e Closing of an lu in the middle of an I/O operation 


The coordination needed for such concurrent events makes data 
communications ESR scheduling different from that of other 
Grivers. 


To coordinate the asynchronous occurrence of ESR requests to a 
Griver, all line drivers usé a special routine (ITSRABS) for 
scheduling ESRs. Standard data communications drivers) might 
require several ESR functions (mainly buffer management) to be 
performed concurrently with IS processing. Other functions, such 
as cancel, halt I/0, power fail or time-out, can occur whenever 
the operating system or the command processor requests them. 


Since several of these regests may be outstanding before any or 
all of them can be completed, there is a mechanism to handle 
multiple requests for ESR scheduling. This mechanism consists of 
a series of bits located in the DCB’ (DCB.ITB). Each bit 
indicates a standard function to be performed during ESR 
processing. The bits are set by the subroutine ITSRABS, which 
‘schedules an ESR when it adds the address of the leaf to the 
system queue if no previous bits were set before this one. Thus, 
only one entry to the system queue is made for many outstanding 
.ESR requests. . 


The actual ESR code executed as a result of an ATL instruction to 
the system queue is a routine called ISSEXEC, which scans’ the 
bits from left to right and executes the indicated subroutine 
corresponding to each bit set. The bit numbers) and their 
correpsonding functions are shown in Table 6-3. 


The ISSEXEC routine is always set up as the next ESR by the SVC15 
executor at connect time. DCB.ESR is set up with the  ISSEXEC 
routine address. Data communications drivers should never call 
EVMOD unless the routine used can perform exactly as ISSEXEC 
performs, especially as far as power fail, time-out or halt I/O 
is concerned; EVMOD modifies the DCB.ESR field. 
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TABLE 6-3 DATA COMMUNICATIONS SUBROUTINE REQUEST BITS 


BIT } FUNCTION {| ROUTINE 
| 0 | Get second buffer for read on RAW =| ITRAWNK 
| 1 | Generate a buffer trap for writes ! ISSBTW | 
! 2 | Set up next chained buffer for write CCB | IT .NXBF | 
| 3 | Perform end buffer processing for write | IT.ENDBF | 
| 4 | Generate a command trap | ISSCT | 
| 5 | Generate a buffer trap for reads | ISSBTR | 
| 6 | Set up next chained buffer for read CCB | IT ..NXBF | 
| 7 | Perform end buffer processing for vena: ! IT.ENDBF | 
! 8 | Time-out occurred (abort I/O) | IT.STOP | 
| 9 | Independent time-out pending expiration | A(CCB.TADR) | 
| 12 | Halt I/O request | IT. .STOP | 
| 13 | Cancel operation (power fail) | IT. .STOP | 
30 ! Final ESR processing ! A(DCB.TERM) ! 
| | | or CMEXIT | 
| 31 | Schedule initiation phase processing | A(DCB.INIT) | 


within driver/terminal manager 


Ee a nl ae lh re a a Dr ee ne en A ee ee Re ee ee ee eed ee ed 


6.6 SUPERVISOR CALL 15 (SVC15) STRUCTURE AND FLOW 


The elements involved in the flow of a typical SVC15 request are 
illustrated in Figure 6-12. Refer to this figure while reading 
the following description of a data communications driver SVC15 
request. 
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The task sets up an SVC15 parameter block and performs an SsvVC15 
instruction. The SVC15 executor uses the lu assignments for the 
task to find the appropriate DCB. If this DCB is a data 
communications DCB and was assigned for SVC15 access, the driver 
initiation routine address is obtained from the DCB.SVCF, and the 
driver is entered in ES(NSU)~ state. Line drivers begin 
interpretation of each DCW command at this time. The fullword at 
DCB.CTA contains the address of the command table to be used for 
command interpretation. The command table contains the address 
of the routines for each of the eight basic categories of 
commands supported by this driver. 


Each routine contains an address table of the specific routine to 
perform the exact function indicated by the modifier. Commands 
that require [I/O must enter an ISR. The ISRs, executing in IS 
state, process all device interrupts. They are responsible for 
placing the adapter and modem into the proper modes required for 
I/O. Once the hardware adapter indicates I/O can proceed, all 
data transfer, character translation and special character 
detection are performed through the auto driver channel of the 
processor. 


The ISRs can schedule ESRs (e.g., the system support routines, 
the buffer management subroutines or the driver termination 
routine) by calling the subroutine ITSRABS. This subroutine, by 
interfacing with the operating system, schedules ISSEXEC as a 
subroutine of the calling task. 


ISSEXEC is responsible for calling the support’ subroutines 
requested by the driver ISRs and for handling certain abort 
situations imposed by the operating system. 


Via the DCB.ITB bit (ITB.ESR), ITSRABS and ISSEXEC also schedule 
the driver termination routine. This routine is responsible for 
continuing DCW command interpretation. After all DCW commands 
are executed, the driver termination routine terminates by 
branching to CMTERM. CMTERM returns the results (e.g., status) 
of the SVC15 call to the user parameter block, generates a 
termination trap, if required, and returns control through the 
operating system. 
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Figure 6-17 SVC15 Line Driver Modules - Data 
Communications Operating System Interface 


6.7 COMMON DATA COMMUNICATIONS SUBROUTINES 

This section details the subroutines included in Perkin-Elmer's 
OS/32 Data Communications Subsystem. Of these subroutines, the 
first five (SVC15, ITRABS, CMTERM, CMEXIT and ISSEXEC) must be 
used by all data communications drivers for entering and exiting 
the drivers. 

6.7.1 Supervisor Call 15 (SVC15) Subroutine 

This subroutine consists of the SVC15 executor entered on any 
SVC15 instruction. It is responsible for validating a request 
and entering the correct driver at the initiation entry. 


The SVC15 routine: 


l. Sets the user condition code (CC) to zero. 
2. Finds the DCB via the lu. 


a. If the DCB is not assigned for SVC15 access, rejects 
call, CC=2, status=illegal lu. 


b. If the DCB is a null device, returns to task, CC#=#4, 
status=0. 
3. Connects the DCB by calling EVCON. 
a. If the DCB is already connected, rejects call, CC-l, 
status unchanged. 


b. Connects and continues. 


4. Relocates DCW pointer. 


An out-of-bounds address terminates the call, status=memory 
fault 1. 


5. Stores the following values in the DCB: 
a. Relocated DCW pointer 
b. Relocated data area pointer 
c. Unrelocated parameter block address 
dad. Relocated parameter block address 
e. TCB number and TCB address 


f. Function code 
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6. Sets a busy status in the user parameter block. 
7. Sets zero status in the DCB. 


8. Zeros out the following: 


a. DCB.NCE (byte) number of commands executed 
b. DCB.AA (halfword) absolute address indicator 
c. DCB.CPTR (fullword) channel program continuation program 


ad. DCB.LLR and DCB.LLW (two halfwords) length of last read 
and write 


9. Sets timer (DCB.TOUT) to X'7FFF'. 


10. Using the address contained in the first data field, finds 
the absolute limits of this logical segment and saves these 
in DCB.BSB and DCB.BSE (if an executive task (e-task), O and 
MTOP are used, respectively). 


ll. Puts the DCB on time chain. 


12. Goes to the driver initiation code by branching to the 
address located in DCB.SVCF. 


6.7.2 ITSRABS Subroutine 


This is the special routine necessary for scheduling ESRs from 
ISRs that must be used by all data communications line drivers. 


ITSRABS is called from drivers during IS to schedule an ESR 
routine. Register 7 is set to the absolute value of the bit 
number that can be set for the required routines. ITSRABS 
performs an ATL of the leaf to the system queue only if no other 
ESR processing bits are set. 


ENTRY: BAL E6 IS state 

E4 = CCB address 

E7 = ESR reason bit number absolute (see ISSEXEC) 
Destroys E3, E5, E7 


6.7.3 CMTERM Subroutine 
This is the equivalent of IODONE2 or IODONE. It is called from 


drivers in either an RS or ES state when the entire SVC15 request 
is completed, either normally or because of error. 
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CMTERM is branched to by the last command in an SsvVC15 request. 
It is essentially the data communications equivalent of IODONE. 
Functionally, it: 


lL. Updates all pertinent fields of the SVC15 parameter’ block 
using values from the DCB. 
a. Status 
b. Length of last read and write 


c. Number of commands executed 


2. Removes the DCB from time chain. 
3. Generates termination trap if requested in function code. 
4. Disconnects leaf. 
5. Exits from ES state via EVRTE. 
ENTRY : Branch CMTERM RS or ES state 
UD=DCB address 


EXIT: Does not return 


6.7.4 CMEXIT Subroutine 


This is the equivalent of TMRSOUT or EVRTE. It is called from 
drivers in the ES state when they exit control so that other 
operations can continue. An interrupt or other operation is 
necessary to get control back to the driver. 


THe CMEXIT routine branches to the channel program/terminalL 
manager via A(DCB.CPCR) if a return was requested or via 
A(DCB.BTRP) if a read buffer trap return was requested. 
Otherwise, this routine branches to EVRTE. 

ENTRY: Branch CMEXIT in ES state 


EXIT: Does not return 


48-077 FOO ROO 6-61 


6.7.5 ISSEXEC Subroutine 


This special ESR is always set up as the ESR to be scheduled by 
any add to top of list (ATL) to system queue for all data 
communications drivers. It is responsible for scanning the 
DCB.ITB bits and calling the proper routines to handle any bits 
set, especially the three bits set by the operating system: 
time-out, power fail ana halt I/0. This is the data 
communications system subroutine executor entered in the ES state 
whenever an ATL instruction to system queue (SQ) is performed for 
a device. It is responsible for handling buffer management 
routines and certain buffer and command trap generation 
functions. This routine scans the bits in DCB.ITB from left to 
right and calls the routines corresponding to each set bit until 
all bits are processed. Then it exits to CMEXIT. The bit 
numbers of DCB.ITB and their corresponding functions are: 


Bit O RAW second buffer 


Scheduled by a read ISR if the read is a 
result of a RAW. Used to get the second 
buffer of a chained buffer since only one 
buffer was set up during read initialization. 
This routine loads UC with the address of the 
read CCB and calls ITRAWNX. 


Bit 1 Generate buffer trap for write 


Scheduled by a write ISR to generate the 
initial buffer trap when I[/0 begins. This 
routine calls IT.TRAP with buffer trap as’ the 
reason. 


Bit 2 Next buffer write 


Scheduled by write ISRs using chained buffers 
when each buffer-is exhausted. This routine 
loads UC with the address of the write CCB and 
calls IT.NXBF. 


Bit 3 End buffer write 


Scheduled by write ISRs after terminating 
write to load register UC with the address of 
the write CCB and call IT.ENDB. 


Bit 4 Generate command trap 


Scheduled by ISRs after completing a write and 
proceeding to the read ISR _ in the RAW 
situation when a command trap is specified in 
the read command. This routine calls IT.TRAP 
with command trap as the reason. 
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Bit 5 


Bit 6 


Bit 7 


Bit 8 


Bit 9 


Bit 12 


Bit 13 
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Generate buffer trap for read 


Scheduled by a read ISR to generate the 
initial buffer trap when I[/0 begins. This 
routine calls IT.TRAP with buffer trap as'- the 
reason. 


Next buffer read 


Scheduled by read ISRs using chained buffers 
when each buffer is exhausted. This routine 
loads UC with the address of the read CCB anda 
calls IT.NXBF. 


End buffer read 


Scheduled by read ISRs after terminating the 
read. This routine loads UC with the read CCB 
and calls IT.ENDB. 


Time-out 


Scheduled by the system clock whenever’ the 
error timer (DCB.TOUT) is decremented to zero. 
This routine calls IT.STOP with time-out 
status, effectively killing the I/O and the 
entire SVC15 request. 


Independent time-out expiration 


Scheduled by the channel terminal manager for 
polling purposes. Branches to the expiration 
routine address given in the timer CCB. 


Halt 1/0 


Scheduled by the SVC15 executor whenever a 
task issues a halt I/O while the task is 
connected for an I/O to the device. The file 
manager also schedules’ the halt I/O routine 
when closing an lu connected for power up I[/0 
if the device has no other assignments. The 
halt I/O routine branches to IT.STOP, with a 
halt I[/O status. 


Cancel (power fail) 


Scheduled by the operating system at power up 
after a power failure. The operating system 
also schedules the cancel routine to cancel a 
task connected to a data communications 
device. The cancel routine branches to 
IT.STOP with a power fail status. 


Bit 30 Final ESR (termination) processing 


Scheduled by line drivers for end of command 
processing. This routine branches to the 
driver termination phase via A(DCB.TERM) or to 
CMEXIT and returns to the terminal manager or 
to the operating system. 


Bit 31 Schedule initiation phase processing 


Scheduled by the IOH functional routines 
( [OHCZBD and IOHMBSC) to invoke’ terminal 
manager initiation via A(DCB. INIT) for 
connected devices. 


6.7.6 ITSETREA Subroutine 


This is a subroutine called from driver IS to schedule ESR 
processing. It is similar to ITSRABS except that the reason 
numbers do not have to be absolute. The subroutine decides 
whether it is performing read or write and modifies the reason 
numbers for reads by adding the appropriate constant (4). It is 
used for common processing for: 


e Buffer traps, reason code=0L 
@e Next buffer, reason code=02, 


e End buffer requests, reason code=03 


ENTRY: BAL E6 IS state 
E4=CCB address 
E7=Reason bit number (as shown above) 
Destroys E3, E5, E7 


6.7.7 ITXFRISR Subroutine 


This is a subroutine that can be called from drivers in I[S_ state 
after the auto driver channel sends a buffer limit interrupt. 
This subroutine checks to see if a buffer is available to the CCB 
as the currently selected buffer. 


Auto driver microcode complements the buffer select bit before 
generating a buffer limit interrupt. If no buffer is available, 
it means all possible buffers have been exhausted and the routine 
returns to the caller. If a buffer is available, a next buffer 
routine is scheduled by calling ITSETREA with E7 specifying next 
buffer request and the routine exits by an LPSWR EO. 
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ENTRY: BAL E5 IS state 
E4=CCB address 


EXIT: Destroys E3, E6, E7 


L. Buffer is available; exit by an LPSWR EO. 


2. No buffer available. 


a. Used last buffer; returm to caller. 


b. RAW next buffer was scheduled but did not execute. Abort 
I/O with buffer overrun 2 status. 


c. Buffer in CCB but the count is positive; 4.e., already 
used. Abort I/O with buffer overrun 2 status. 


dad. Buffer in CCB is flagged as busy. 
e. Buffer in CCB is flagged as done. Abort I/O with buffer 
overrun 1 status. 

6.7.8 ITISSTOP Subroutine 
This routine can be called from IS code to terminate I/O because 
of errors. E7 is loaded wtih the status for the error. ITISSTOP 
Gisables both read and write sides of the adapter and clears the 
interrupt service pointer (ISP) table entries to III. ITISSTOP 


then ORs the new status to the accumulated status, schedules a 
halt I[/0 by calling ITSRABS and exits by an LPSWR EQ. 


ENTRY: Branch ITISSTOP IS state 
E4=CCB address 
E7=Error status 


EXIT: | Does not return 


6.7.9 IT..STOP Subroutine 


This is a common data communications routine used to abort an I/O 
call because of error conditions. This subroutine: 


l. Disables read and write sides of a device using DCB.DOCR with 
DCB.RDN and DCB.DOCW with DCB.WDN, respectively. 


2. Sets ISPTAB entry to III for read and write device numbers. 
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3. ORs status halfword contained in register 7 to the latest 
status in DCB.ISTA. If the encoded portion of DCB status is 
nonzero, the encoded portion of the status in register 7 is 
stripped off before it is ORed. 


4. Branches to driver ESR obtained from DCB.TERM. 
ENTRY: Branch IT..STOP ES state 
UD(13)=DCB address 
U7=Status (new status) 
EXIT: Either CMEXIT or 
branch via A(DCB.TERM) 
6.7.10 ITIMLINK Subroutine 


This subroutine is used to enter a data communseetsons CCB into 
the timer chain for the 100ms clock. 


At time-out, the clock removes CCB from the timer chain and 
generates an SINT. 


CCB.SUBA and the ISPTAB should be set up prior to any call to 
ITIMLINK. 
ENTRY: BAL U8 ES state 
UC(12)=CCB address 
EXIT: Returns via U8 
Destroys U9, UA, UB, UE 
6.7.11 ITIMUNLK Subroutine 
This subroutine is used to remove a CCB from the timer chain. On 


return, the condition code (CC) indicates whether or not the CCB 
was on the chain at the time of the call. 


CC=G if CCB was on chain. 
cc=0 if CCB was not on chain. 
ENTRY: BAL U8 ES state 


UC=CCB address 


EXIT: Returns to address in register 8 
Destroys U9, UA, UB, UE 
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6.7.12 ITISTOTC Subroutine 


This subroutine is used to remove a CCB from a timer’ chain. It 
is called from the driver IS state and is similar in action to 
ITIMUNLK except that it must be called from the ISRs of drivers 
and it uses different registers. On return: 


CC=O if CCB was not on chain. 
CC=G if CCB was removed from chain. 
ENTRY: BAL ES IS state 
E4=CCB 
EXIT: Returns via E5 


Destroys E6, E7 


6.7.13 ITISPOTC Subroutine 


This subroutine adds a CCB to Lhe Limer chain Lor the 100ms 
clock; called from IS state only. 


ENTRY: BAL E5 IS state 
E4=CCB 
EXIT: Returns via ES 


Destroys E6, E7 


6.7.14 ICMDINT Subroutine 


This subroutine fetches and interprets DCW commands by performing 
the following six functions: 


l. Increments the number of commands executed in DCB.NCE by 1. 


2. Fetches the next DCW command from the halfword pointed to by 
DCB .DCW. 


3. ANDs the buffer trap and command trap bits of the command 
with the corresponding bits of the function code and saves in 
register 3. 


4. If the command trap is requested and enabled, generates a 
command trap by calling IT.TRAP with the command trap as the 
reason (reason code X'OA'). 


5. If the command indicates time-out, sets the error timer 
(DCB.TOUT). Otherwise it stops the timer by setting DCB.TOUT 
to X'7FFF'. The time value used is obtained from DCB.ITV for 
READ and PREPARE commands. All other commands use DCB.OTV. 
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6. Uses the least three bits of the command to index into the 
command table (located by DCB.CTA), obtains the code address 
to handle this command, and branches to it. A zero entry in 
the table indicates that the command is unsupported and 
results in an illegal command status. 


ENTRY: Branch ICMDINT ES state 
UD(13)=DCB address 


EXIT: Branches to proper command obtained from 
command table 
UD=DCB address 
UA=Address of ITGETMOD 
U5=Address of ICMDILL (illegal command 
handler ) 
U3=Command 


Branches to illegal command handler for 
illegal commands. 


Destroys U7, U8, U9, UB, UC, UE 


6.7.15 ITGETMOD2 Subroutine 


This subroutine is the second entry to ITGETMOD and is used by 
commands that do not require a CCB (e.g., the NULL command). The 
routine performs the same functions as ITGETMOD, but it does not 
store the commmand in the CCB or clear the CCB, since none is 
provided. 


ENTRY: See ITGETMOD 


EXIT: See ITGETMOD 


6.7.16 ITGETMOD Subroutine 


This subroutine is used by driver commands to enter the code for 
a specific modifier. Each driver command specifies its 
appropriate modifier table, maximum modifier and CCB. ITGETMOD 
stores the commands in the CCB, clears the CCB of any buffers and 
validates that the modifier is less than or equal to the maximum 
allowable modifier. It is then used to index into the modifier 
table to fetch the address of the routine responsible for 
handling this specific request. If the address fetched is 
negative, a branch on register 5 is performed. This allows 
commands to perform some common preprocessing before actually 
branching to the code for a specific modifier. 
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ENTRY : Branch ITGETMOD ES state 
U3=Command 
U5=Address for negative modifier return 
U6=Number of entries in modifier table 
U7=Address of modifier table 
UC=CCB address (not required for ITGETMO2) 
UD=DCB address 


EXIT: If a modifier table entry is positive, 
branches to that location. 


If a modifier table entry is negative, 
branches to address in U5 entry fetched from 
the table is in U6. 


If a modifier table entry is zero, aborts 
entire SVC15 request by branching to illegal 
command handler. 


Destroys U8, UA, U6 


6.7.17 ITGETDAT Subroutine 


This subroutine is called from commands that require a data 
field. This routine fetches the next data field in order and 
returns to the caller with the data field in register 7. The 
pointer to the next data field (DCB.NDA) is incremented by 4, 
causing successive calls to ITGETDAT fetch sequential data 
fields. If the data field fetched is negative (data codes of 
X'80'), ITGETDAT relocates the address contained in the field by 
calling ADCHK and replaces the data field pointer (DCB.NDA) with 
the new value. Data fetch then continues from the beginning, 
effectively causing a transfer out of the normal data field 
sequence. 


ENTRY: BAL UF ES state 
UD=DCB address 


EXIT: ' U7=Data field fetched 
Destroys U8, U9, UA, UB 
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6.7.18 ITGETBUF Subroutine 


This subroutine is used by all data communications drivers 
supporting standard buffer management. The routine fetches the 
Gata field, calls ITBFREL to relocate the address and sets up the 
CCB for a data transfer of the proper size using the buffer type 
specified by the data code. Options contained by U4 are: 


e If the get one bit is set (X'4000'), only the first buffer of 
a possible set of chained buffers is set up in the CCB. 
Otherwise, two buffers are set up. This option is usually 
requested in the read of a RAW, where only one buffer must be 
available. Get one has no effect on direct or indirect 
buffers. 


e If the data code indicates a data area instead of a buffer 
(data code X'Ol') as used by READ] or READ2, the low-order 
four bits of the option word contain the size of the I/O. 
Routine ITGETBUF uses ITBFREL to relocate buffers and ADCHK to 
relocate data areas. 


ENTRY: BAL U2 ES state 
U4=+Options 
UC=CCB address 
UD=DCB address 


EXIT: Destroys U5, U6, U7, U8, U9, UA, UB, UE, UF 


6.8 SUPERVISOR CALL1 (SVC1) PROCESSING 

Processing an SVCl call for a data communications device differs 

from processing standard devices in the following ways: 

e For data-transfer calls to buffered terminals, terminal 
manager entry is made in ES/NSU state. 

@e Upon termination of an SVCl call (in IODONE), the ISP table 
entry is not modified for data communications devices. 

6.9 ADDITIONAL EXECUTIVE FUNCTIONS 

OS/32 executive handling of certain functions is redefined for 


data communications devices as explained in the following 
sections. 
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6.9.1 Cancellation of Input/Output (1/0) 


On power restoration and when a task is cancelled, the TIMEOUT 


routine is called. For data communication devices, time-out 
calls the HALTITAM routine in the data communications system 
support module. This routine performs the normal actions of 


timing out an I/O. However, it also sets a bit in DCB.ITB that 
can be used by the driver or terminal manager to determine if the 
situation is a halt I/O (unrecoverable) rather than a recoverable 
time-out. 


6.9.2 Add To Task Queue 


The SV9.ATQ routine is modified to accept reason codes 10, 11, 
12, 13, 14, 15, 16 and 17 whenever these codes are enabled by bit 
23 of the TSW. It is also possible to determine if an 
unsuccessful return is due to a full, nonexistent or invalid 
queue; the former sets only the L bit in the CC, the latter two 
set both C and L bits. To indicate the reason for an error, 
SV9.ATQ returns with the L bit set in the CC if a queue is full 
or with both L and C bits set for a nonexistent or invalid queue. 


6.9.3 System Initialization 


The SYSINIT routine is modified to set up initial values for the 
Gata communications timer and DCBs for data communications 
devices. 


6.9.4 Timer Management 


An additional timer is maintained for data communications 
‘devices. It allows interval timing with a granularity of 100ms 
and is maintained by a chain of CCBs. Routine ISRLFC is modified 
to maintain an additional counter, ITM.FREQ, which is initialized 
to the line frequency divided by five. At every interrupt from 
the LFC, this counter’ is decremented by one. When it reaches 
zero, the counter is reset to one-fifth the line frequency and 
ISRLFC continues to decrement TM.FREQ by one-fifth the line 
frequency, rather than one. If the address of the first CCB in 
the ITAM timer chain (ITAMTIMC) is nonzero, an ESR is scheduled. 


Routine TIMESR is modified for the possibility that it may be 
entered once every 100ms for data communications timer handling. 
When this happens, it follows the CCB chain and decrements’ the 
value of CCB.ITAM. When this value goes to zero, the device is 
SINTed and ITISTOTC is called to remove the CCB from the chain. 
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6.10 SUPERVISOR CALL 7 (SVC7) PROCESSING 


The standard OS/32 module FMS7 does preliminary processing on all 
SVC7 function calls. For any data communication-related request, 
FMS7 branches to individual function routines within the _ ITFM, 
the data communication file and memory manager program. 


6.10.1 Allocate 


The IT.ALLOC routine processes allocate requests for data 
communication devices. Entry to this routine is in the RS state. 
To obtain the DCB address, IT.ALLOC calls the DMTLOOK routine. 
To enter the appropriate allocation routine (i.e., IT.ABSC for 
allocating a BISYNC LCB, or IT.ADCT for allocating a ZBID DCT), 
IT.ALLOC uses the main line-type index: 


Illegal 
BISYNC LCB 
ZBID DCT 
ZDLC LCB 


iohk won 


WHE O 


At entry, each of the allocation routines: 


1. Disable the SQS routine. 
2. Verifies filename and station-address uniqueness. 


3. Obtains and initializes memory space. 
On exit, each routine enables the SQS routine. 


6.10.2 Delete 

The IT.DELET routine processes deletion requests for data 
communications devices. Entry to this routine is in the RS 
state. To enter the appropriate deletion routine (i.e., IT.DBSC 
for deleting a BISYNC LCB, or IT.DDCT for deleting a ZBID DCT), 
IT.DELET uses the main line-type indexes specified above. 


At entry, each of the deletion routines: 


l. Disable the SQS routine. 
2. Finds a matching LCB or DCT and removes it from the chain. 


3. Releases memory space. 


On exit, each routine enables the SQS routine. 
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6.10.3 Assign 


The IT.OPEN routine processes assignment requests for data 


communications devices. Entry to this routine is in the RS 
state. After checking the extended device code to see if the 
line is 2-wire or 4-wire, IT.OPEN' sets up the device-number 


entries (for reads and writes) within the DCB. 


For an SVC15 assignment, IT.OPEN calls OPEN.SVCF to complete any 
necessary validity checks, to set up the read count and write 
count within the DCB and to set up the lu table. For an SvVCL 
assignment, IT.OPEN calls OPEN.DEV to perform normal validity 
checking, as with all nonbulk devices, and calls IT.ORJE to 
perform data communications-related functions. 


To enter the appropriate assignment routine (i.e., OPEN.RJE for 
a BISYNC LCB, or OPD.NRJE for all other devices), IT.OPEN uses 
the main line-type indexes. If IT.OPEN branches to OPEN.RJE, 
this allocation routine calls LCBLOOK to: 

lL. Find the LCB address. 

2. Ensure no previous assignment to the found LCB. 

3. Set up the read count and write count within the DCB/LCB. 

4. Set up the lu table to include the LCB address. 

At exit, either assignment routine returns control to the SVC7 
mainline coding. . 

-6.10.4 Close 

The IT.CLOSE routine processes closing requests for devices 
assigned SVC15 access. The CLOS.RST routine processes closing 
requests for nonbuffered devices assigned SVCl access. For SVC1l 


buffered devices using main line-type indexes, IT.CBSC closes 
BISYNC devices, and IT.CDCT closes ZBID devices. 


48-077 FOO ROO 6-73 


6.10.5 Checkpoint 


The IT.CHKPT routine processes checkpointing requests for data 
communications devices. For nonbuffered devices and for devices 
assigned SVC15 access, IT.CHKPT waits for ongoing [/0 to end 
before returning control to the operating system. For SVC1 
buffered device using main line-type indexes, IT.KBSC checkpoints 
BISYNC devices and IT.KDCT checkpoint ZBID devices. Both of 
these routines: 


Wait for ongoing I/O to end. 
Call HALTITAM. 


Flush the various buffer management queues. 


mm WW NO ff 


Exit to the operating system. 


6.10.6 Fetch Attributes 


The IT.FETCH routine fetches attributes for data communications 
devices. For nonbuffered devices, IT.FETCH returns only the 
device mnemonic to the user's parameter block. For buffered 
devices, IT.FETCH extracts the block size, fd and device code and 
returns them to the user. 


6.10.7 Change Access Privileges 


For data communications devices assigned SVC15 access, read-only 
or write-only privileges cannot be granted. For buffered devices 
assigned SVCl access, the address of the CB must be obtained from 
the LCT. 


6.10.8 Rename 

The REN.DCB routine changes the DMT entry for the device. Also, 
this routine changes LCB.NAME and LCB.EXT when it finds a 
buffered data communications terminal. 

6.10.9 Reprotect 

As determined by SVC7 parameters passed by the user, the REP.DCB 
routine changes the read keys and the write keys. Also, if an 


ITAM device is buffered, REP.DCB must get the DCB address’ from 
the LCB. 
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CHAPTER 7 
HOW TO WRITE AND USE A TERMINAL MANAGER 


7.1 INTRODUCTION 


In data communications, a large number of special-purpose line 
protocols and data format variations within standard protocols 
are possible. Consequently, it may be necessary to provide a new 
terminal manager that satisfies a nonstandard protocol or an 
interface not currently supported by Perkin-Elmer. The purpose 
of this chapter is to assist the design analyst and system 
programmer with the creation of a new terminal manager. It is 
not oriented toward the modification of any specific existing 
terminal manager and should be considered a general guideline to 
be used along with other pertinent Perkin-Elmer publications and 
protocol specifications. Where possible, examples of functional 
requirements are provided with reference to existing terminal 
managers. 


7.2 TERMINAL MANAGER MODIFICATION 


Terminal manager modification might involve preparation of a 
newly designed terminal manager to add new features to channel 
program line control using existing format routines. It could 
also add new format capabilities using existing channel programs 
or could remove existing nonrequired features from aé_e standard 
terminal manager. 


Existing terminal manager utility routines and tables designed to 
support general format and protocol control functions, should be 
used whenever possible as they can be easily applied to new 
terminal manager applications. Determine if the terminal manager 
needs to be modified. For example, if only new line control 
procedures are required, using a standard supervisor call 15 
(SVC15) driver request from an application program may be more 
appropriate. If only new format procedures are required, adding 
format subroutines to an application program and obtaining line 
access via SVCl image reads and writes might be sufficient. 


7.3. BACKGROUND INFORMATION 
Terminal manager modification might require some background 


information depending on how much is to be modified and the 
program areas that will be affected by the changes. 


48-077 FOO ROO 7-1 


To remove trailing blank suppression from the existing 
teletype/video display unit (TTY/VDU) terminal manager, only 
cursory knowledge of the operating system and data communications 
is required and the TTY/VDU terminal manager program description 
might suffice as an information source. To design a totally new 
buffered terminal manager, extensive background information 
concerning the operating system and data communications may be 
required. 


@e An understanding of the internal structural design, module 
interface and table structure of the operating system 
Executive and File Manager is recommended if any interface to 
the operating system is to be modified or created. While such 
knowledge of the operating system is highly recommended, 
existing data communications /operating system interface 
subroutines should be sufficient for most applications. 


e Design criteria, internal structure and module interfaces are 
required for formatting or channel program modification using 
common data communications subroutines. 


@® Design criteria and detailed descriptions of the SVC15 line 
Griver supporting your terminal manager are required for any 
terminal manager modification involving interface with the 
line driver or format routine modification to change the 
control character sequence passed to the line driver. 


@ General-purpose driver design criteria should be obtained > 
prior to terminal manager modification. 


@ Detailed specifications concerning the protocol to be 
supported are required for all terminal manager modifications. 


7.4 TERMINAL MANAGER STRUCTURE 


While the specific actions to support terminal manager protocol 
control and data formatting vary for different applications, the 
high-level functions performed by all terminal managers are 
similar. Three terminal manager functional flowcharts are 
provided in Figures 7-1, 7-2 and 7-3. While not indicating every 
piece of code a terminal manager can contain, these flowcharts 
provide a guideline to general terminal manager design. 


7.4.1 Nonbuffered Terminal Manager 


Based on the design of the existing TTY/VDU terminal manager, 
Figure 7-1 depicts terminal manager requirements for using 
standard SVCl task connection control and for performing 
input/output (1/0) into and out of the task data buffer. This 
design is similar to a standard OS/32 driver except that it uses 
SVC15 routines for actual line I/O. 
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Figure 7-1 Nonbuffered Terminal Manager 
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7.4.2 Buffered Terminal Manager (Input) 


Based on the design of the existing binary synchronous’ terminal 
manager, Figure 7-2 depicts the requirements of a terminal 
manager to control input through single or dual internal buffers, 
attempt to read ahead of the user task (u-task) and perform its 
own task connection control. 
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Figure 7-2 Buffered Terminal Manager (Input) 
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7.4.3 Buffered Terminal Manager (Output) 


Based on the design of the existing binary synchronous’ terminal 
manager, Figure 7-3 depicts the requirements of a terminal 
manager that controls output through single or dual _ internal 
buffers, is behind the u-task in actual writes due to data 
buffering and performs its own task connection control. 
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Figure 7-3 Buffered Terminal Manager (Output) 
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7.5 TERMINAL MANAGER FUNCTIONS 


This section describes the individual blocks within the terminal 
manager flowcharts. Functions performed in more than one 
flowchart are described only once. These block descriptions 
should be read as an addendum to Figures 7-1, 7-2 and 7-3. 


@e BLOCK A 


All terminal managers are initially entered from SVCl handlers 
via the I/O handler (IOH) list. For entrance to nonbuffered 
terminal managers, the device control block (DCB) address is 
in register U13. For entrance to buffered terminal managers, 
the line control block (LCB) address is in register U13. 


@ BLOCK B 


Basic program initialization procedures include interpreting 
data communications extended options, setting default extended 
options as required, determining and setting up the register 
environment, etc. Routine PCINT of the binary synchronous 
terminal manager can perform these initialization functions. 


@ BLOCK C 


If a communications line was not readied to accord with a 
protocol, certain special-purpose actions might be required. 
Within existing terminal managers, the busy bit (LNS.BSYB) in 
the line status description word, DCB.LNST, determines if the 
line was previously readied. The control actions required can 
be determined from the extended device code, DCB.XDCD. If 
line initialization is not required for a particular 
application, exclude this area. 


e BLOCK D 


Line initialization is the first of a sequence of functions to 
ready a communications line for data transfer. Depending on 
individual requirements, it can involve dial-in/out, polling 
or terminal selection, line bid transmission/reception or line 
password or security check. Priority control of master/slave 
stations, prevention of line bid clashes and similar error 
control can also be included. 


® BLOCK E 


This is a simple format subroutine. For example, within the 
existing TTY/VDU terminal manager, a carriage return (CR) 
character terminates an output data buffer and all trailing 
blanks are truncated. Similar format control routines can be 
included at this same functional location. A nonbuffered 
terminal manager should not modify data within a user buffer, 
as the same buffer could be used simultaneously by the u-task 
or another driver or terminal manager. 
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@ BLOCK F 


Preparation for an SVC15 read includes setting time-out values 
and building SVC15 command and data chains. It is convenient 
to define standard command chains within the terminal manager 
and build data chains depending on individual circumstances 
within the DCB. 


@ BLOCK G 


Preparation for an SVC15 write is similar to a read 
preparation, described in Block F. Within either of these 
areas, it might be necessary to cancel any outstanding timers 
(SVC15 wait requests) required by the individual protocol. 


@ BLOCK H 


Actual entry into the line driver and final DCB initialization 
for SVC15 is best achieved by a common subroutine. The 
terminal manager/line driver interface is currently provided 
by a branch to the address found within the DCB at DCB.SVCF 
with the DCB address contained in register UD. Dual return 
paths are provided to a continuation address found in DCB.CPCR 
and to a final I/O termination address found in DCB.CPTR. The 
existing SVC15 interface subroutine within the binary 
synchronous terminal manager (SVC15GO) saves the command chain 
address for possible retries, sets an I/O active bit within 
the line status word, clears SVC15 status words and puts’ the 
DCB on the common OS/32 timer chain. 


e BLOCK I 


The common exit subroutine IRLOUT is a way to terminate driver 
action pending the final satisfaction of the user request. 
The exit is to EVRTE. If the application program performed 
proceed I/O, it can regain control at this point. 


@e BLOCK J 


A common subroutine can be used to check for possible errors 
following all communications line I/Os. This might include a 
line/hardware error or an invalid data response depending on 
protocol requirements. It is necessary to differentiate 
between errors the terminal manager might retry and 
unrecoverable errors. As this is a common point following all 
Svc15 line interfaces, it is a possible point at which to 
include an 0OS/32 journal entry. The binary synchronous 
ERRORSET subroutine can be used to perform these basic 
functions. 
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BLOCK K 


When an error return to the user program must be made, convert 
the SVC15 status or protocol failure to a standard SVCl error 
code by using an SVCl status table indexed by the SVC15 status 
return. 


BLOCK L 


Within even basic nonbuffered terminal managers, certain 
protocol-dependent actions might be required following I/O 
completion. The TTY/VDU terminal manager, for example, 
determines if a line delete character was received on a read 
and transmits a line feed (LF)/CR/CR sequence on writes. 


BLOCK M 


Before a return to the user program, certain common = status 
areas must be set for the SVCl parameter block. These include 
device-independent status, DCB.STAT, driver-dependent status, 
DCB.DDPS, if applicable, plus length of last transfer, 
DCB .LLXF . 


BLOCK N 


The exit subroutine DONE is a way to terminate driver action 
following completion of a user request. The exit may be to 
IODONE or to a specialized routine for post-I/O processing and 
task disconnection, as required. Normally, the application 
program performing SVCl wait I/O regains control through this 
exit point. 


BLOCK O 


Within buffered terminal managers, it might be advisable to 
perform task connection within the terminal manager instead of 
having SVCl perform it. This allows a task to be connected to 
a line at the beginning of a transmission sequence and remain 
connected to it throughout the entire transmission. A common 
application of this procedure allows a task to be connected 
for a read with the line initialization sequence (see Block 
D), and later suspend the read before it starts in favor of a 
write request. This technique requires that the terminal 
manager perform internal checks to ensure proper handling of 
proceed 1/0 requests. A task can perform proceed I/O, regain 
control through IRLOUT, and issue a second request before 
completing the first. For proper handling of such requests, 
the standard terminal manager technique is to set a hold bit, 
LNS.HLDB, within the line status word if exit is made to 
IRLOUT prior to request satisfaction. If this bit is set upon 
terminal manager entry, the second request is put into a wait 
state pending completion of the first. 
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@ BLOCK P 


The standard 0S/32 subroutines EVCON and EVQCON are used for 
task connect. An 0OS/32 utility subroutine, WAIT, puts a task 
into wait I/O pending completion of an earlier request. 


@® BLOCK Q 


No data can be moved into a user buffer unless a line I/O was 
previously performed. If data is not ready for the user, 
initiate a read and a return to this’ point, following a 
successful line read. Initiate this code in either reentrant 
state (RS) or event state (ES) state. Because of this, it is 
important to ensure against interlace of proceed requests as 
described in Block O. 


@ BLOCK R 


This block contains the crux of the protocol-dependent channel 
program with all ACK/NAK sequences, line error detection and 
corrections. 


@e BLOCK S 


This block indicates setting the LNS.HLDB prior to an exit to 
IRLOUT and before completing a user request. See Block O. 


@ BLOCK T 


This block is reached only after completing a successful line 
I/O. It depicts checking LNS.HLDB and returning to data 
formatting, if required. See Block O. 


@e BLOCK U 


This block shows all data input deblocking, formatting and 
moving of data to a user buffer. Should a new protocol 
subformat be required, such as a 3270 emulation within binary 
synchronous, only this block requires modification such as 
removing existing format subroutines and replacing them by 
3270 format procedures or exception code to perform 3270, 
3780, 2780 or processor-to-processor formatting, as required. 
An existing subroutine within binary synchronous, DCDINDEX, 
can provide an exception code table index dependent on format 
decode. 
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BLOCK V 


This block depicts checking for a possible readahead if dual 
block buffering is used. Before any readahead, the terminal 
manager checks for the availability of an _ input buffer, 
existence of any concurrent line I/O and other conditions that 
might preclude such an action. 


BLOCK W 


A readahead is performed like any data _ read. Following 
successful read completion, the block is put on queue for 
deblocking and checking LNS.HLDB for possible return to data 
formatting. 


The readahead technique generally allows an interface to 
operate at maximum line speed as opposed to ae slower 
combination of line speed and user program return speed. 


BLOCK X 


This block depicts all data output blocking, formatting and 
moving of data from a user buffer. Since I/O is performed in 
an internal buffer as opposed to the user buffer, data 
modification is permitted in accordance with protocol 
standards. See Blocks E and U. . 


BLOCK Y¥ 


After the last user record is moved into an internal buffer, 
that data buffer is ready for output. This ready condition 
should be indicated to the channel program by the _ format 
subroutine. 


BLOCK Z 


Following write preparation, the actual write may be delayed 
and the write buffer only put on queue for output. Reasons 
for a delay could include existing data [I/O if dual buffering 
is used, the expiration of the wait timer or other 
protocol-dependent conditions. Return to this point is 
required following removal of the delay. This area must be 
able to operate in either RS or ES state, similar to the 
dual-state read sequence described in Block Q. 


BLOCK AA 
If a ready buffer cannot be output, put it on queue for output 


and establish a hold state until output initiation. See Block 
O. 
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e@e BLOCK AB 


After line data I/O initiation, return to the user is 
accomplished only if it is possible to accept a subsequent 
user request; i.e., another buffer is available for 
deblocking. 


e BLOCK AC 


After a successful data write, determine if a subsequent data 
block is ready for output. If not, return to the appropriate 
write preparation routine. 


7.5.1 Special Terminal Manager Functions 


Special terminal manager functions are performed within existing 
terminal managers. If an existing similar terminal manager is 
available, study each major function in it before preparing any 
similar routines for a new terminal manager. Wherever possible, 
terminal manager subsections and utility subroutines were 
prepared in a modular format to permit easy modification, 
replacement, removal or use in a different environment. 


7.5.1.1 Format Control 


As shown in Figures 7-1, 7-2 and 7-3, data format blocking and 
deblocking routines are subroutines of the data transfer 
preparation section. Inserting a new format subroutine iS a 
straightforward process. Within existing format control 
subroutines, special character scans are performed by moving the 
involved data through a translate table. Single format 
subroutines achieve multiple format techniques with control bit 
registers. For example, internal space suppression is performed 
only if the perform space suppression bit is set in a_ control 
register. The correct control bit register is generally set by 
a subroutine based on device code DCB.DCOD, data communications 
extended device code DCB.XDCD and extended options DCB.XITO. 


7.5.1.2 Time-out Control 


Usually, communications protocols require time-out delays (SVC15 
wait) to be initiated between data transfers. Time-out 
expiration may require transmission of a protocol-dependent data 
delay signal or request. Common subroutines exist to set timers 
via the SVC15 WAIT command and to cancel outstanding time-outs 
prior to data transfer and determine if the time-out has already 
expired. An invalid return to the program might occur if a data 
transfer is attempted simultaneously with an earlier SVC15 
time-out data transfer request. Within the binary synchronous 
terminal manager, use the ONTIMER subroutine to set a delay timer 
and the OFFTIMER subroutine to cancel an existing time-out. 
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7.5.1.3 Buffer Control 


There are subroutines to access or change the status of internal 
data buffers. Where appropriate, an error return is provided. 
These routines are: 


BUFFERO Release buffer 
Error exit if invalid address provided 


BUFFER1 Obtain write blocking buffer 
Error exit if nonavailable 


BUFFER2 Obtain active read deblock buffer 
Error exit if nonavailable 


BUFFER3 Obtain free buffer 
Error exit if nonavailable 


BUFFER4 Obtain write buffer on queue for output 
Error exit if nonavailable 


BUFFERS5 Is there a free buffer? 
Error exit if no free buffer 


BUFFER6 Is there a buffer with I/0 al progress? 
Error exit if not 


BUFFERS Free all buffers 
No error exit 


BUFFERY Place buffer on queue 
No error exit 

7.6 SYSTEM GENERATION (SYSGEN) CONVENTIONS 
See the System Generation/32 (Sysgen/32) Reference Manual for 
sysgen considerations. To generate the proper basic data 
communications code, SGN.ITAM must be set to l. 
7.6.1 Register Conventions 
In the binary synchronous terminal manager, strict adherence to 
register conventions was an aid in system implementation. These 


conventions are recommended for future terminal manager 
modifications: 
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UO Work (may be destroyed by any subroutine) 


U1 DCB address 

U2 LCB address 

U3 Block descriptor address for format 
subroutines (LCB.BLK) 

U4 Function code (DCB.FC) 

U5 Extended option function code (DCB.XITO) 

U6 Line status code (DCB.LNST) 

U7 Level O subroutine entry or return 

U8 Level 1 subroutine entry or return 

U9 Level 2 subroutine entry or return 

U10-U15 Work (may be destroyed by any subroutine) 


7.6.2 Device Control Block/Line Control Block (DCB/LCB) 
References 


Future data communications modifications may involve 
reorganization of a DCB or LCB. For this reason, do not use the 
following coding techniques: 


@e Reference to any DCB or LCB element by an absolute value as 
opposed to its symbolic name. 


e Reference to any DCB or LCB element to require certain DCB/LCB 
elements to be adjacent. This includes load halfword of 
currently adjacent bytes, load fullword of currently adjacent 
halfwords and similar multiple load techniques. 


7.6.3 EXTRN/ENTRY References 


Certain EXTRN/ENTRY references are required to ensure proper 
0OS/32 interface. Although specific applications might require 
different interface points, the list of the external references 
currently used by the binary synchronous terminal manager should 
suffice. af 
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IT.HALT 


BEBC.ASC 


ISSEXEC 


WAIT 


TMREMW 


JOURNAI. 


TOCHON 


TOCHOFF 


ITI 


ISPTAB 


[ODONE / IODONE2 


EVRTE 


TWT .RJE 


CPT.RJE 


CLOSMBSC 


INI TMBSC/FUNCMBSC 


is an external reference to the halt I[/0 
subroutine. 


is an external reference to the binary 
synchronous line driver ASCII-to-EBCDIC 
translation table. 


is an external reference to the system 
subroutine executor. 


is an external reference to the executive 
wait subroutine. 


is an external reference to the 0S/32 
remove task wait subroutine. 


is an external reference to the 0S/32 
system journal subroutine. 


is an external reference to the 0S/32 
subroutine to put a DCB on a timer chain. 


is an external reference to the 0S/32 
subroutine to remove a DCB from a timer 
chain. 


is an external reference to the 08/32 
subroutine to ignore interrupts. 


is an external reference to the interrupt 
service pointer table. 


is an external reference to the 0OS/32 I/0 
completion exit points. 


is an external reference to the 0S/32 
exit points. 


is an entry reference to the _ subroutine 
to determine whether or not a terminal 
manager is busy. 


is an entry reference to the terminal 
manager checkpoint subroutine. 


is an entry reference to the terminal 
manager close subroutine. 


is an entry reference to the terminal 
manager entry points from SVCl. 
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7.6.4 System Generation (Sysgen) 


Following assembly of a new terminal manager and its associated 
DCBs, standard sysgen procedures can be used to add the new 
terminal manager and its associated DCBs to the 0OS/32 system. 
The new terminal manager and DCBs must be merged into the 
combined driver library using the OS/32 Library Loader. The only 
restrictions on the required order of modules within the library 
is that the DCBs for all devices supported by a particular driver 
or terminal manager must precede the driver or terminal manager. 


7.7 WRITING TERMINAL MANAGERS SUMMARY 


The following procedures provide a user-written terminal manager: 


@e Determine if a new terminal manager is actually required. 
Where practical, use a standard terminal manager in image mode 
or applications program SVC15 access. 


e Gain thorough familiarity with areas involved. Study existing 
terminal managers to determine which major sections or 
subroutines can be used. Consult the individual line driver 
descriptions to determine how these capabilities can be best 
used. 


@e Test and implement the new integrated communications package. 


7.8 HOW TO USE DATA COMMUNICATIONS TERMINAL MANAGERS 


This section provides a sample program containing four coding 
examples to illustrate the structure of data communications SVC1 
parameter blocks and the execution of SVCl reads and writes. A 
CAL STRUC is provided to generate equates for all parameter block 
references, and each used parameter block is laid out with 
explanatory comments. The parameter block labelled LINEBLK is 
used for all functions, and the parameter blocks READBLK and 
PRINTBLK are used for other SVCl accesses. The following four 
coding examples describe these functions. 


Example 1: 


This example illustrates a loop reading from an input device 
(e.g., a terminal) and writing each record to a bisynchronous 
terminal manager. The loop terminates when it recognizes an 
input sentinel and an end of file (EOF) is written to the line. 
No extended options are used. 
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EXAMPLE] EQU . 


x 
* THE FOLLOWING USER EXAMPLE WILL READ 
* CARDS FROM LOGICAL UNIT 1 AND 
x WRITE EACH CARD RECORD TO AN ITAM 
x COMMUNICATIONS LINE ON LOGICAL UNIT 2 
x UNTIL A 
x CARD BEGINNING WITH // IS FOUND. IT 
x WILL THEN WRITE AN EOF. 
x 
SVC 1, READBLK READ A CARD 
LH U15,READBLK+SVC1.STA CHECK FOR ERROR 
BNZ DONE 
LH U15, BUFSTART SEE IF LOOP IS DONE 
CLHI U15,C'//' a 
BE EOF 
svc 1,LINEBLK WRITE CARD TO ITAM COMM LINE 
LH U15, LINEBLK+SVC1.STA CHECK FOR ERROR 
BNZ DONE 
B EXAMPLE 1 CONTINUE LOOP 
EOF EQU * 
LHI U15,X'88' MODIFY PARAMATER BLOCK 
STB U15,LINEBLK+SVC1.FC TO WRITE EOF 
Svc 1, LINEBLK WRITE EOF TO COMM LINE 
DONE EQU * 
Svc 3,0 END OF JOB SVC 
ALIGN ADC 


READBLK EQU * 
DB X'48',1,0,0 
DAC BUFSTART, BUFEND 
DAC 0,0,0 


LINEBLK DB x"28*,2,0,0 
DAC BUFSTART, BUFEND 
DAC 0,0,0 


Example 2: 


This example illustrates the use of data communications extended 
options. The data communications parameter block (LINEBLK) is 
modified to include a write with extended options and the format, 
transparent and transmission extended options, are set. A single 
record is then read from an input device and written to the 
terminal manager. After write completion, the example goes to 
end of job. The transparent and transmission extended options 
are not honored on all devices. 
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EXAMPLE EQU x 


THE FOLLOWING USER EXAMPLE WILL 
x READ A SINGLE CARD FROM LOGICAL, 
x UNIT 1 AND WRITE IT AS A SINGLE 
- RECORD TRANSMISSION, TRANSPARENT 
* TEXT TO AN ITAM COMMUNICATIONS 
* LINE ON LOGICAL UNIT 2. 
* 
x 
LHI U15,X'29' SET UP WRITE FUNCTION CODE 
STB U15,LINEBLK+SVC1.FC USING ITAM EXTENDED OPTIONS 
LI U15,SV1X.FM+SVC1X.TRM+SV1LX.TM SET UP ITAM EXTENDED 
ST U1L5, LINEBLK+SVC1. EXO OPTIONS 
SVC 1, READBLK HEAD A CARD 
LH U15,READBLK+SVC1.STA CHECK FOR ERROR 
BNZ DONE 
svc 1,LINEBLK WRITE TO COMMUNICATIONS LINE 
B DONE 
Example 3: 


Illustrates a loop reading record from a terminal manager and 
writing each input record to an output device (e.g., a printer). 
When an error from the line is received (e.g., an EOF), the loop 
terminates and the example goes to end of task. 


EXAMPLE3 EQU- * 


* 
* THE FOLLOWING USER EXAMPLE WILL 
* READ SUCCESSIVE CARD RECORDS 
x FROM AN ITAM COMMUNICATIONS 
x LINE ON LOGICAL UNIT 2. 
x EACH RECORD WILL BE PRINTED ON 
* LOGICAL UNIT 1. UPON RECEIPT 
* OF AN EOF OR OTHER ERROR RETURN 
* FROM ITAM, THE TASK WILL 
x TERMINATE 
x 
LHI U15,X'48' SET ITAM PARAMETER BLOCK FUNCTION 
STB U15,LINEBLK+SVC1.FC CODE FOR A READ. 
EX3LOOP EQU) * 
Svc 1, LINEBLK READ FROM I'TAM 
LH U15, LINEBLK+SVC1.STA CHECK FOR ERROR 
BNZ DONE DEPART FOR AN ERROR 
SVC 1, PRINTBLK WRITE TO THE PRINTER 
LH U15,PRINTBLK+SVC1.STA CHECK FOR ERROR 
BNZ DONE DEPART FOR ERROR 
B EX3LOOP CONTINUE LOOP 
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Example 4: 


Illustrates the use of the disconnect extended option. A data 


communications 


extended options. 


parameter 


block is built to write a record using 
The format and disconnect extended options are 


set. Upon completion, the example goes to end of job. 


EXAMPLE4 EQU 


ee uM He He He He ee 


svc 


x 


THE FOLLOWING USER EXAMPLE 
WILL MAKE A SINGLE RECORD 
WRITE TO THE COMMUNICATIONS 


LINE ON LOGICAL UNIT 2. 


THE 


USER REQUEST USES ITAM EXTENDED 


OPTION WITH A REQUEST 


TO DISCONNECT THE LINE FOLLOWING 
THE WRITE. AFTER THE WRITE, THE 


TASK GOES TO END OF JOB. 


U15,xX'29' 
U15,LINEBLK+SVC1.FC 
U15,SV1X.FM+SV1X.DM 
U15,LINEBLK+SVC1.EXO 
U15, PRINTOUT 
U15,LINEBLK+SVC1.SAD 
U15, PRINTEND 
U15,LINEBLK+SVC1.EAD 
1, LINEBLK 

3,0 


PUT WRITE WITH. EXTENDED OPTIONS 
FUNCTION INTO PARAMETER BLOCK 
FORMAT AND DISCONNECT 

EXTENDED OPTIONS 

SET UP PRINT-LINE START AND 
END ADDRESSES 


EXECUTE THE TERMINAL MANAGER SVC 
GO TO END OF JOB 
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CHAPTER 8 
HOW TO WRITE AND USE DATA 
COMMUNICATIONS LINE DRIVERS 


8.1 INTRODUCTION 


Data communications covers a broad range of transmission types, 
line protocols, character sets, modems, terminals and terminal 
idiosyncrasies. Since the basic data communications subsystem 
cannot support every possible configuration, the purpose of this 
chapter is to assist the system programmer’ responsible for 
modifying or writing a data communications line driver. 


8.2 MODIFYING A LINE DRIVER 

Before modifying a driver or writing a new driver, determine the 
functions performed by a typical line driver, where they are 
performed and which functions require modification with existing 
drivers as a working base. 

In general, data communications line drivers perform some or all 
of the following steps during a supervisor call 15 (SVC15) 
request: 


1. Common driver initiation processing 


2. Command fetch of the basic command category 


ie) 


Common command processing 

4. Modifier fetch of the specific command 
5. Data field fetch 

6. Address relocation 


7. Data buffer initialization and channel control block (CCB) 
setup 


8. Initialization of adapter and modems 
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9. Transfer of actual data 


a. Internal/external character set translation 
b. Detection of special characters 
c. Buffer limit processing 


dad. Error status processing 


10. Ending sequence processing and adapter disabling 


ll. Event service routine (ESR) processing 


a. Restart at Step 2 if command is chained 


b. Terminate the call if in error or completed 


Steps 1 through 7 are nearly device-independent. They are 
basically the same for all drivers observing the standard data 
communications command and buffer format. Steps 8, 9 and 10 are 
concerned with the type of modem and characteristics of the 
attached terminal. Steps 8, 9c, 9d and 10 are performed by the 
interrupt service routines (ISRs) of the command. The auto 
driver channel, with the assistance of the translation table 
whose address is in CCB.XLT, performs Steps 9a and 9b. 


For example, the existing asynchronous line driver supports a 
103-type modem. If support for a 202-type modem using reverse 
channel is desired, new ISRs are required to handle the different 
status interrupts caused by the reverse channel. Different 
output commands are required to enable and disable the adapter. 
These should be assembled in the new device control block (DCB). 


If the attached terminal communicates in ASCII, only the new ISRs 
that handle the interrupts are required along with the new DCB 
containing the desired output command bytes. Figure 8-1 shows 
the structure of a typical data communications line driver. 
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aes an eee 2 eee SONDXEED 
COMMAND CONTROL CONTROL 
TABLE CODE MODIFIER EXAMINE 
Ce oS aEAD 
ae | READ CODE MODIFIER REDD 
| READ CODE | TABLE BEADZ ISRs 
TRANSLATION eee | SaESARE SAEEREE READ BUF 
POINTER | A 
a | CODE MODIFIER PREPARE 
TERMINATION ASC.EBC | 
ed EBGASC_| |} 
| 
TRANSLATION] ||| 
TABLE 1 o 
SPECIAL 
CHARACTER 
TRANSLATION ROUTINES OF 
TABLE 3 TRANSLATION 


TABLE 


TRANSLATION 
TABLE 2 


SPECIAL 
CHARACTER 
ROUTINES 


TEST CODE 


Figure 8-1 SVC15 Driver Structure 


As another example, assume that the attached terminal can 
interface to a 103-type modem but communicates in EBCDIC (or any 
other character set). The addition of two new translation 
tables, ASCII-to-EBCDIC for output and EBCDIC-to-ASCII for si 
would be required. 


Most specialized requirements would need: 


e Different translation tables 
@ Special character handling subroutines 


e ISRs to handle interrupts in a device-dependent (modem) manner 


The standard command format and buffer management’ should be 
maintained. A similar asynchronous or binary synchronous line 
driver should be studied as an example. Much of the basic data 
communications subsystem is table-driven, so modifications or 
additions require a table change and the _ additional code 
necessary to perform the new feature. 


8.3 LINE DRIVER USE OF THE DEVICE CONTROL BLOCK (DCB) 


A separate DCB is maintained for each device (adapter) in the 
system. It is the DCB that controls the flow of any SVC15 
request by allowing each device to specify its particular 
requirements. The DCB maintains control of the SVC15 request 
through these fields: 


DCB.INIT is the pointer to the initiation code for all 
SVC15 requests to this device. 

DCB .CTA. is the address of the command table that 
contains pointers to the code for each of the 
commands supported by this device. Some 


commands may be common with other drivers; 
other commands may be specially designed. 


DCB .MOCR 

DCB .MOCW are the bytes used with output comnand 

DCB.DOCR instructions to control the adapter for a 

DCB . DOCW particular attached modem and terminal. 

DCB .DISK 

DCB.AOC is the byte used to load programmable adapters 
with the information required to control the 
communications line attached (line speed, 
character size and parity information). 

DCB.XLT is the pointer to the table of valid driver 


translation tables. 
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DCB .TERM is the pointer to the driver termination code. 


DCB .RDN are the halfwords indicating the device 

DCB .WDN numbers to use when reading and writing to the 
connected adapter. Depending on the adapter 
strapping, these numbers’ may be the same or 
different. These numbers are initialized by 
the file manager using the 2-wire/4-wire 
indication in DCB.xDCD to determine device 
strapping. 


DCB.XDCD is the extended device code field initialized 
at sysgen that supplies information about the 
intended use of the communications line. 


DCB .ESR is the address of the ESR to be scheduled 
during system queue service (SQS). 


8.4 LINE DRIVER STRUCTURE 


The actual code to handle a specific request (command and 
modifier) is depicted by the boxes on the right side of Figure 
8-1. The routines are entered by indexing through ae series of 
tables beginning at the DCB (left side of Figure 8-1). New 
commands or features can be added by specifying a new table that 
points to the old command routines that remain unchanged and to 
the new routines for the added features. 


Much of the code needed by line drivers handles command and 
modifier fetching and buffer management. This is usually 
consistent throughout all line drivers supporting the standard 
data communications format and has been implemented in 
subroutines maintained in the data communications module. The 
user-written line drivers should use these supplied routines. If 
the standard data communications command format and buffer 
management is followed, a specialized driver would require ISR 
code to handle the adapter and translation tables to handle the 
character set involved. 


8.4.1 Driver Initiation Routine 


Drivers are entered in the ES (NSU) state and command 
interpretation begins immediately. Commands performing 
input/output (1/0) require interrupt service (IS) (execution is 
in the IS state), eventually ending in event state (ES). Any 
additional commands in the command chain are interrupted and 
executed in the ES state. Normally, the drivers exit to the 
supplied routines CMEXIT and CMTERM. 


Routine CMEXIT is like TMRSOUT or EVRTE and is used whenever’ the 
driver desires to exit and wait for a condition to reactivate it. 
Routine CMTERM is’ like IODONE or IODONE2 and is used to end an 
SVC15 request and, if required, to generate a termination trap to 
the calling task. 
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SVC15 instruction execution by a task results in entry to the 
line driver in the ES(NSU) state at the initiation address given 
by the DCB.SVCF, with UD13 containing the address of the DCB. 
Most drivers at this time begin driver command word (DCW) command 
execution by branching to the supplied routine ICMDINT. However, 
the driver might initialize programmable adapters at this time or 
perform some other introductory operation. Once ICMDINT is 
entered, the driver is controlled by the command table and the 
DCB. 


8.4.2 Translation Tables 


Translation tables can exist anywhere in memory. However, all 
special character subroutines referenced by the tables must be in 
pure code located below 64K. 


To make changes in translation as easy as possible, drivers make 
no absolute reference to any character. A driver can have a code 
to handle a terminating character, but the translation table and 
the translation table routines decide what constitutes such a 
character and branch to the code that handles it. A change of 
translation table and possibly some output commands’ supplied in 
the DCB, should orient the supplied driver toward a new device 
while maintaining compatibility with the devices for which the 
driver was originally designed. 


All basic data communications special character routines begin 
with a Load Halfword Immediate (LHI) instruction to load a 
register with the translated character. This instruction must 
not be squeezed by CAL/32 to allow line drivers to perform a 
software translation of all characters, including special 
characters, since the translated value of any character is always 
the second halfword of each routine. 


8.5 DATA COMMUNICATIONS LINE DRIVER EXAMPLE 


This section is to guide the reader through the code of a typical 
line driver. To write a new line driver that handles reads’ and 
writes using the existing buffer management and command format 
but requires a new protocol and different handling of the modem 
interface, the standard routines supplied for NULL and CONTROL 
should be adequate. No support is required for the MODE or 
PREPARE command. 


8.5.1 Command Table 


First, a command table referencing the necessary commands is 
required. This table usually is a part of the driver and must be 
aligned on a _efullword boundary and have a label declared as an 
ENTRY in the driver. This label is referenced as an EXTRN by the 
DCB. The command table can be coded as follows: 
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ENTRY UWCOMTAB 
EXTRN ITAMNULL, ITAMCTRIL 


ALIGN ADC ALIGN TABLE ON FULLWORD 


UWCOMTAB EQU ~ 
DAC I TAMNULL USE STANDARD NULL 
DAC ITAMCTRI USE STANDARD CONTROL 
DAC UWREAD USER WRITTEN READ 
DAC 0 NOT SUPPORTED (PREP) 
DAC UWRITE USER WRITTEN WRITE 
DAC 0 NOT SUPPORTED (HOLD) 
DAC 0 NOT SUPPORTED (MODE) 
DAC 0 NOT SUPPORTED (TEST) 


The initiation code for the driver must begin with a label of the 
form INITxxxx just as for general-purpose drivers. This is 
Geclared as an ENTRY in the driver and an EXTRN in the DCB. The 
reference to the line driver in the DCB is in DCB.SVCF instead of 
DCB.INIT, since DCB.INIT is reserved for the address of the 
terminal manager, if supported. 


8.5.2 Command Fetch 


Routine ICMDINT locates the first command in the DCW string, uses 
the least significant three bits to index into the command table 
and branches to the code to perform that command. If the command 
specifies command traps or time-out, the trap is generated or the 
timer started before entering the command. If the command is a 
NULL or CONTROL, the routine ITAMNULL or ITAMCTRL is entered, 
indicated by the command table. If the command is a WRITE, the 
user-written routine UWWRITE is entered. The command halfword is 
in U3 and the DCB in UD (the user-written routine in the center 
of Figure 8-1) can perform any desired function or initialize 


programmable adapters, if necessary. To enter the code to 
perform the exact function indicated by the modifier, use a data 
communications routine and a user-supplied table. The basic 
command (WRITE, in this case) can access’ the code for each 


modifier by the following steps: 

1. Loading UC with the address of the write channel control 
block (CCB) 

2. Loading U7 with the address of the write modifier table 

3. Loading U6 with the maximum allowable modifier 


4. Branching to the ITGETMOD routine 


The command halfword is still contained in U3 and the DCB address 
is always maintained in UD. 
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8.5.3 Modifier Fetch 


The CCB is cleared of all buffers by ITGETMOD, which then places 
a copy of the command in the CCB after clearing the unused four 
bits (bits 4 through 7) and branches to the code for the function 
specified in the modifier table. 


NOTE 


All loads of CCB addresses must use the 
LHI instruction since the CCB address is 
stored in a halfword that might be 
located above 32K. 


8.5.4 Command/Modifier Routines 


Each particular command (right side of Figure 8-1) must’ perform 
all the processing required to complete its defined function. If 
data fields are required, they can be fetched by calling 
ITGETDAT, which returns with the next data field in U7. If bit 
0 of the data field is set (data code X'80'), ITGETDAT performs 
a data field transfer by relocating the address contained in the 
data field and using this to continue the data field fetch. 


Data fields contain the addresses in user program space of data 
required by the driver. These addresses must be relocated to 
absolute values to be useful to drivers. Data buffer addresses 
can be relocated by calling ITBFREL. All other addresses must be 
relocated by calling ADCHK. 


The routine ITBFREL assumes all buffers are in the same _ logical 
segment as the address contained in the first data field of the 
SVC15 parameter block. 


The command can now load the data from this address and perform 
the required operation. Mode commands, for example, merely store 
the data in selected places in the DCB. READ and WRITE commands 
must transfer data into or out of this location. They use the 
address and the data code to set up the CCB for a data transfer 
using the buffer type specified by the data code through the 
ITGETBUF routine. 
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A call to ITGETBUF works to fetch the data field, relocate the 
address and set up the CCB for a transfer of the proper size 
data. It uses the buffer type specified by the data code. The 
least significant four bits of the data code are also stored in 
bits 4 through 7 of the command kept in the CCB. If the command 
is a short write such as WRITE2 (maximum of 15), this number is 
placed (ORed) into the low-order four bits of the options 
register, U4, before calling ITGETBUF. 


If read after write lookahead is supported, a check is performed 
to see if the present command (WRITE) is chained. If so, RAWCHKR 
(referenced as an EXTRN) is called. This routine checks to see 
if the next command is a READ. If so, RAWCHKR sets a read after 
write (RAW) pending flag in the DCB, sets the get one buffer flag 
in the options register, and fetches and enters the READ code. 
The READ command performs as if it were fetched normally and can 
initialize programmable adapters or any other introductory read 
operation. It performs the following steps: 


1. Loads UC with the address of the read CCB 
2. Loads U7 with the address of the modifier table 
3. Loads U6 with the maximum valid modifier 


4. Branches to ITGETMOD 


The ITGETMOD routine performs the same operations conducted in 
fetching the WRITE and enters the code for the indicated type of 
READ. This code also sets up the read CCB for a READ using the 
appropriate buffer type by calling ITGETBUF. The READ is now 
ready to begin. However, if a RAW pending flag is found, it 
returns to the WRITE code. 


8.5.5 Entering Interrupt Service Routines (ISRs) 


Returning from a call to RAWCHKR, the WRITE code sets up the 
channel command word (CCW) of the CCB (CCB.CCW) to ensure that 
the execute bit is off and that the other bits are appropriate 
for the write. Most likely, the write and the translate bits are 
also set. The subroutine pointer in the CCB (CCB.SUBA) is loaded 
with the address of a pure routine, an ISR in the driver. The 
address of the CCBtl is stored in the ISPTAB entry for the write 
device number, and a_e simulate interrupt (SINT) instruction is 
performed using a write device number. The routine now exits by 
branching to CMEXIT. 
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The SINT instruction simulates an interrupt and therefore enters 
the ISR. User-written drivers can perform whatever is necessary 
here; however, most drivers try to place the adapter and the 
modem into write mode, assuming that the adapter is in an unknown 
state. This is done by issuing an output command using the byte 
in the DCB reserved for placing the adapter in write mode with 
interrupts enabled (DCB.MOCW). The address of CCB.SUBA can now 
be changed to point to the next ISR and the routine exits by a 
Load Program Status Word Register (LPSWR) instruction. Each 
interrupt causes the second ISR to be activated. The following 
registers are loaded by firmware: 


EO Program status word (PSW) status before the 
interrupt 

El PSW location before the interrupt 

E2 Device number causing the interrupt 

E3 Status of device causing ena dneeerupe 

EB4 Address of the CCB 


This second ISR generally ignores all interrupts until the 
adapter is ready for data transfers (indicated by zero status). 
ISRs exit by the LPSWR using register EO. They can use registers 
E2 through E7 without restoring them; E8 through E15 can be used 
only if saved and stored. 


Once the adapter is ready for the transfer (status equal zero), 
the CCB.SUBA is loaded with the address of an ISR to handle the 
interrupts from the auto driver channel. The execute bit is 
turned on in the CCW. The first character is obtained from the 
buffer by a call to ITFC, translated by the TLATE instruction and 
written to the adapter. The CCB pointers are adjusted by the 
Simulate Channel Program (SCP) instruction, and the ISR exits by 
loading the PSW from register EO. 


All future interrupts from the adapter are handled by the auto 


driver channel (microcode) and assistance from the driver is 
required only for one of the following reasons: 


@e Error status interrupts 
e Buffer limit interrupts 


@ Special character processing 
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An error status interrupt is usually an indication to abort I/0 
by loading the appropriate status in register E7 and branching to 
ITISSTOP. This routine stores the status, disables the device 
(both read and write), clears the ISPTAB entries and schedules 
the halt I/O routine, terminating the entire SVC15 request. 


A buffer limit interrupt means the CCB has just used the last 
byte from the buffer and complemented the buffer select bit in 
the CCW of the CCB. When using chained buffers, the driver must 
determine if another buffer is available. If another buffer is 
available, the driver keeps the I/O going with the second buffer 
while a third buffer is readied by scheduling the next buffer 
write routine. All these operations are done by calling ITXFRISR 
to schedule the next buffer routine, if there is a need for it, 
or to return to the caller and indicate that no more buffers are 
available. Each individual driver can treat this situation as 
appropriate. The binary synchronous driver treats it as an error 
and indicates that a proper terminating sequence was not 
encountered. The asynchronous driver considers it a normal 
completion. The ITXFRISR routine checks for certain error 
conditions, and if any exist, aborts the entire SVC15 request 
with the appropriate status. These errors are concerned with 
chained buffers and the condition of the busy and done bits or 
with the fact that a next buffer write routine was scheduled, but 
had not yet executed. 


8.5.6 Special Character Routines 
Special character routines are entered as a result of the 


translation table and are responsible for the following 
procedures: | 


e Translating the character by an LHI instruction, since each 
routine is for a specific character. 


e Performing the required function of the character (change 
modes, terminate the I/O or backspace). 


e Writing the translated character to the adapter or storing it 
in the buffer, as appropriate. 


@e Performing cyclic redundancy checks (CRC) or longitudinal 
redundancy checks (LRC), if necessary. 


e Increment ing the porneare of the CCB so that character count 
is correct. 


@ Handling any buffer limit situations that occur during the 
previous step. 
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8.5.7 Read After Write (RAW) Turnaround 


At some point, the ending character, ending sequence or buffer 
limit condition can terminate I/0. The adapter is disabled by 
issuing an output command using the command byte in DCB.DOCW and 
is usually set up to disable the adapter while keeping it in 
write mode. The end buffer write routine is scheduled by calling 
ITSRABS. This routine takes care of the last buffer and adjusts 
the length of the last write indicator in the DCB. If the RAW 
pending flag is set, the driver ISR calls the routine ITWR.RD to 
perform the following steps: 


@e Increment the current DCW pointer 

e Set transfer not begun in status halfword 

e@e Set up the ISPTAB entry for the read device number 

@e Load E2 with the read device number 

e Load E3 with the read status 

@e Load £4 with the read CCB 

e Start read error timer if command requests time-out 

@ Schedule RAW second buffer if chained buffers are used 

@e Schedule command trap read if command requests it 

@e Increment number of commands executed 

@e Adjusl current DCW pointer 

e Return to caller, who branches to the first read ISR 

The read ISR now performs like the write ISR, placing the adapter 
in read mode by using DCB.MOCR and waiting for an interrupt with 
the proper status (usually zero). If buffer traps are requested 
in the command, the trap is scheduled by calling ITSRABS with the 
proper reason number. CCB.SUBA is loaded with the address of the 
read ISR to handle the interrupts from the auto driver, the 
execute bit is set and the I/0 proceeds as in the write. Buffer 
limit, error status and special characters are handled just as in 
the write ISR. The read ISR, using DCB.DOCR, eventually 
terminates by disabling the adapter, schedules the end buffer 


read routine and the driver-termination routine by two calls to 
ITSRABS, and exits by the LPSWR instruction. 
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8.5.8 Driver-Termination Phase 


The driver-termination phase routine, whose address is in 
DCB.TERM, checks the status halfword in DCB.ISTA and terminates 
the SVC15 request if any errors exist by branching to CMTERM. 
When no errors exist, the driver ESR checks to see if the current 
command is chained and, if so, fetches and executes the next 
command; this 18 accomplished by the routine ITNXTCMD. This 
routine checks the current DCW command and, if it is chained, 
increments the DCW pointer and branches to ICMDINT, which 
continues with command interpretation. When the command is not 
chained, ITNXTCMD returns to the caller. The entire SVC15 
request can then be terminated by branching to CMTERM. 


8.6 USING DATA COMMUNICATIONS LINE DRIVERS 


Except for interrupt handling routines whose code is executed in 
the IS state, data communications line drivers execute in the 
ES(NSU) state with SQOS turned off. 


Drivers fetch and execute each command of a DCW chain. When a 
command goes to an error-free completion and if the chain command 
bit of the command is set, the next command in line is fetched 
and executed. This sequence of fetch and execute is repeated 
until the entire DCW chain is successfully interpreted or until 
an error condition in any command terminates the SVC request. 


Commands can be arranged in any order; however, each command is 
interpreted one at a time and at user priority. A command chain 
consisting of three consecutive writes is interpreted as three 
complete and separate write operations that are fetched, set up, 
executed and terminated one at & time. On a high-speed CRT, 
delays may appear between the writes. 


If the preceding sequence of three writes were issued to the 
binary synchronous driver, each write would begin by sending a 


series of leading synchronous’ characters. In addition, each 
write would end with the proper binary synchronous’7 termination 
sequence. If this sequence is not supplied, an error results. 
An analogous’ situation exists for chained reads. Data 


communications is generally interactive and involves a write 
request followed by a read request, such as: 
e Write prompt character(s) and read data 


e Write a buffer and. read acknowledge (ACK) or negative 
acknowledge (NAK) 


e Write ACK or NAK and read buffer 


e Write poll or select and read response 
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Data communications allows a write command chained to a read 
command to be handled as one continuous command, both of which 
are fetched and set up before any I/O begins. The write is then 
performed. Upon completion, the line is immediately turned 
around and the read is performed. Once I/O for the write 
actually begins, the entire sequence (write and read) is 
performed regardless of task priority and in a manner totally 
transparent to the user. 


In addition to the RAW lookahead, there is a read after prepare 
lookahead that allows a task to chain a read to a prepare. Thus, 
a task can scan a communications line for a _ special (prepare) 
character and immediately enter the read command to read any 
following data. 


8.6.1 Buffer Management 


Buffer management currently supports four buffer types: 


@e Direct 
e Indirect 
e Chained 


@® Queued 


Direct and indirect buffers each consist of a single buffer that 
must be sufficient to complete a single write or read command. 
The term complete means that the buffer contains one or more 
terminating characters (if required for writes) or enough buffer 
space to hold one or more terminating characters (if required for 
reads). Chained and queued buffers consist of one or more linked 
buffers. It is through the use of chained and queued buffers 
that most flexibility is achieved. The entire series of buffers 
must be sufficient to complete a command. The use of buffers is 
illustrated as follows: 


e Figure 8-2 is a sample SVC15 parameter block to write data 
from a direct buffer. 


e Figure 8-3 is a sample SVC15 parameter block to read data (an 
SVC15 parameter block reading) into an indirect buffer. 


e Figure 8-4 is a sample SVC15 parameter block to read data into 
a series of chained buffers. 


e Figure 8-5 is a sample SVC15 parameter block to read data into 
a series of queued buffers. 
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I/O has a double-buffering capability. However, when a_e single 
buffer (direct, indirect or single chained) is specified for a 
read or write, only one buffer can be used. If I/O reaches’ the 
end of the buffer, the line driver receives a buffer limit 
interrupt. Buffer limit interpretation is driver-dependent. For 
example, the asynchronous driver terminates error-free when 
buffers are exceeded, while the binary synchronous driver returns 
a buffer limit status if a proper terminating sequence did not 
occur before buffer limits were exceeded. 


077-15 
SVC15 PARAMETER BLOCK DCW CHAIN OF 1 COMMAND 
FC Lu | STATUS l-—— HaLFwoRD-——>} 
## CMDS A (DCW) 0004 (WRITE) 
LLR | LLW 
00 A (START) DIRECT BUFFER 
00 A (END) }-—syte—o 
ea eee rs 
BYTE- | DATA BYTE 2| 
HALFWORD DATA BYTE 3 
———— FULLWORD | 
n-END START+1 END | DATA BYTE n | 
Figure 8-2 SVC15 Using Direct Buffers 
077-16 
SVC15 PARAMETER BLOCK DCW CHAIN OF 1 COMMAND 
STATUS + HaLFworD ——> 
#CMDS — 0002’ (READ) 


INDIRECT BUFFER 


DATA BYTE 1 DATA BYTE 2 


DATA BYTE n 


A = BUF) 


BYTE - an 


HALFWORD 


DATA BYTE 4 
—-——-— FULLWORD 


Figure 8-3 SVC15 Using Indirect Buffers 
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SVC15 PARAMETER BLOCK : DCW CHAIN OF 1 COMMAND 


J naurwono—4 
| # cmos | A (DCW) 
oe A (CHN.BUF1) 


fod . CHN.BUF 1 
HALFWORD 
FULLWORD 
_ A (CHN.BUF3) 


CHN.BUF2 BYTES AVAIL BYTES USED 
D2 


ee Ce 
To Po [oe [| 


CHN.BUF3 BYTES AVAIL 


Figure 8-4 SVC15 Using Chained Buffers 
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077-18 SVC15 PARAMETER BLOCK OCW CHAIN OF 1 COMMAND 
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Figure 8-5 SVC15 Using Queued Buffers 
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8.6.1.1 Chained Buffers 


When chained buffers are specified, the driver attempts to set up 
two I/O buffers. This means that for the task to use more than 
a single chained buffer for 1/0, it must supply at least two 
linked buffers when the SVC15 request is issued. These two 
buffers are set up; the first buffer is flagged as busy (bit 0 of 
link word set) a buffer trap is generated, if specified and I/0 
starts. When buffer 1 is exhausted, the driver receives a buffer 
limit interrupt and finds buffer 2 is available (busy and done 
bits reset) and uses this buffer to continue I/O. Meanwhile, a 
routine is scheduled to flag buffer 1 as done, flag buffer 2 as 
busy, and attempts to set up the first I/O buffer using the 


current link word of buffer 2 as a pointer. If this link is 
zero, the current buffer is the last buffer of the chain and the 
I/O must terminate within it. If the Link word is nonzero, it 


indicates the location of buffer 3. At this time, buffer 3 does 
not necessarily have to be available (busy and done bits reset) 
as long as its address is specified. A buffer trap is generated 
to the calling task. However, buffer 3 must be available before 
the next buffer limit interrupt. If it is not, the buffer 
overruns and I/O aborts; the status reflects this overrun. 


In RAW, the driver looks ahead and sets up only one read buffer. 


Therefore, if chained buffers are used for the read, only one 
buffer is set up in advance. When the driver terminates the 
write, one buffer is ready for the read. If the read uses 


chained buffers, a subroutine to get the next buffer schedules 
immediately after performing the write to read turnaround. The 
buffer trap for the read is performed after read I/O begins. 
Getting only one read buffer instead of two is useful when using 
chained buffers for both write and read. However, the buffer 
trap for the next to last write buffer must be identified by the 
u-task because the task must specify the second buffer in the 
link word of the first read buffer before the driver completes 
the write. 


When interpreting commands, the driver uses two pointers that are 
updated during command fetching and execution: 


e The current DCW pointer that points to the current DCW being 
executed. If the command is chained, it is updated after each 
command goes to completion. 


e The next data field pointer pointing to the data field to be 
used on the next data field fetch. It is updated after each 
Gata field is fetched. 


This example illustrates how these pointers are used. It also 
illustrates the transfer in Data Facility and the TRANSFER 
command. 
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DCW COMMAND 


NUMBER DATA FIELD COMMAND CHAIN NUMBER 
lL 00 BUF1.STRT cc WRITE BUFFER L 
2 00 BUF1.END cc READ BUFFER 2 
3 04 BUF2 cc XFER 3 
4 O01 A(command 1) 
5 80 A(data 1) 


Execution of the command chain and data chain results’ in 
continuous I/O consisting of the following: 

@e A WRITE from buffer 1 (direct text) 

@ A READ into buffer 2 (indirect text) 

@e A branch back to a write from buffer 1 (direct text), thus 


repeating the write/read sequence indefinitely or until an 
error occurs. 


At starting time, the: 


@ current DCW points to the WRITE (command 1), and 


@e the next data field points to BUFISTRT (data field 1). 


The first command is fetched and the write routine is entered, 
which sets up for the write by fetching a data field. Since the 
Gata field indicates a direct buffer, a second data field is 
fetched. Now the pointers show the following: 


@ The current DCW pointing to WRITE (command 1) 


@e The next data field pointing to BUF2 (data field 3) 


Before actually writing the data, the driver looks at the next 
command and finds it to be a read. Therefore, the read code is 
entered. The read routine sets up for the read by fetching a 
data field. Since the data field indicates an indirect text 
buffer, the driver is satisfied. After setting up for the read, 
the read routine finds. that it was entered from a write and 
returns to write without performing any I/O. The pointers now 
show the following: 


@e The current DCW pointing to WRITE (command 1) 


e The next data field pointing to data field 4 
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Write I/O is performed and, on error-free completion, the write 
termination routine finds a RAW situation, bumps the current DCW 
pointer and enters the READ code. The pointers now show: 


e The current DCW pointing to READ (command 2) 

e The next data field pointing to data field 4 

After the READ goes to completion, a routine is scheduled to 
check the command to see if it is chained. Since it is, the 
current DCW pointer changes to fetch the next command. The 
pointers now show: 

@e The current DCW pointing to XFER (command 3) 

@e The next data field pointing to data field 4 

The XFER routine fetches data field 4 (the address of command 1) 
and changes’ the DCW pointer to the value contained in that data 
field, affecting a branch. The next command is fetched again. 
However, the pointers show: 

@ The current DCW pointing to WRITE (command 1) 

e The next data field pointing to data field 5 

The command fetch brings the WRITE routine into action again. It 
fetches data fields and finds the X'80' data code, indicating 
that the data field contains the address of another data field. 
The next data field pointer is updated to the contained value. 
The pointers now show: 

@ The current DCW pointing to WRITE (command 1) 

e The next data field pointing to BUF1.STRT (data field 1) 

The WRITE code again attempts to fetch a data field to use _ for 
buffers. 

8.6.1.2 Line Driver Data Communications Device Interface 

The line drivers provide a simple interface to standard data 


communications devices and allow enough flexibility for effective 
control of the particular communications network. 
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A simple communications network can be controlled by the use of 
only three commands: READ BUFF, WRITE BUFF and WAIT. Assuming 
that move commands are not needed to change default parameters, 
the user merely reads or writes information regardless of 
communication variables like line speed, character size, line 
parity, type of line (2-wire, 4-wire, leased), type of adapter, 
programmable asynchronous single line adapter (PASLA), 
quad-synchronous adapter (QSA) or type of modem. 


While the line drivers do handle the specific operating 
requirements of the actual communications line interface 
(computer, adapter and modem), they are unaware of any line 
Giscipline or protocol. The user provides the correct 


handshaking procedure or dialogue with the other end of the line, 
if any is required, by chaining appropriate WRITE and READ 
commands . 


While complex DCW chains can be constructed, commands are fetched 
and executed in an interruptible state at the priority of the 
calling task. Ensure that the task's priority is commensurate 
with the requirements of the line, especially when using the more 
sophisticated chained buffers. 


Although commands are fetched and interpreted in an interruptible 
state, special provision is made for the unique sequence of write 
chained to read. In this situation, after the write is set up, 
but before actually starting I/0, the driver checks to see if the 
write is chained to a read. If it is, the read is also set up. 
This way the driver can turn a line around very quickly and be 
ready to receive the data regardless of task priority. 


Intelligent terminals usually operate with a protocol that 
requires each end to ACK or NAK receipt of a message. Therefore, 
to communicate information to such a device, issue a write 
(containing your message) chained to a read (to accept the ACK or 
NAK). The driver relocates and sets up the write and read 
buffers and the write is performed. When write completes, the 
line is turned around and read is performed. When read 
completes, the driver has finished the SVC15 request. The status 
is stored in the user's SVC15 parameter block, and if canceled, 
a termination trap is generated. Now look at the read buffer and 
determine whether the message should be repeated (received an 
NAK) or the next message should be written (received an ACK). 


If the user is receiving a data message from the device, the 
message must be acknowledged to indicate error-free (ACK) or 
invalid (NAK) reception by the write chained to read sequence. 


First issue an SVC15 read to get the message. After SVC15 
completes, check the status (and optionally the data) and reply 
with an SVC15 write chained to read. The write specifies ACK or 
NAK (reply to the last message), and the chained read readies the 
driver to receive a new message (if ACK) or a repeat of the 
message (if NAK). 
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Once write to read turnaround is done, the driver has one buffer 
transfer time to set up additional required buffers. If, due to 
heavy processor loading, these operations are not performed in 
time, I/0 is terminated on detection of the buffer overrun 
situation and the status is set to reflect this (status=buffer 
overrun). Take appropriate recovery action (retry I/O). 


Assume that the task is an interactive interpreter that, once 
started, requests input from a remote terminal. Normally the 
computer writes out a statement number (sequence number) and then 
initiates a read to the terminal in several ways, using the SVC15 
request. 


Method 1: 
The sequence number is maintained in one buffer. 


Buffer 1 is a direct buffer of eight characters, containing two 
carriage return (CR) characters, one line feed (LF) character, a 
4-digit ASCII sequence number and a space. Writing this buffer 
causes the four sequence numbers to appear on the terminal at the 
left margin of a new line. 


Buffer 2, an indirect buffer of 60 characters, receives the 
input. By using an indirect buffer, the number of characters 
actually entered can be determined without scanning the input for 
special characters. The first supplied halfword indicates to the 
driver how many bytes are available for data character storage. 
The actual number of characters read by the driver is stored in 
the second halfword of the buffer. 


A user could issue a write from buffer 1 and then a read _ into 
buffer 2. Adequate response time for the read can be assured and 
system overhead can be saved by issuing only one SVC15 for both 
the write and read. The SVC15 parameter block and associated 
Gata are shown in Figure 8-7. 


The function code specifies termination trap. The DCW chain 
contains the following: 


e A WRITE command specifying a chain to the next command when 
this write is error free. 


e A READ command. The read does not have the time-out bit set 
and is able to wait indefinitely for input. The read is not 
chained. When this command completes, SVC15 terminates by 
storing certain values in the parameter block and by 
generating a termination trap (requested in function code) to 
the user program. 


If the response at the terminal was A=B CR, the parameter block 
and associated fields might be as shown in Figure 8-7. 
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Method 2: 


Since the interpreter is just one of many programs running in a 
multitasking environment, unacceptable delays might occur between 
responses from the task because of higher priority tasks. 


To inform a remote terminal of the status of the input attempt, 
it might be desirable to establish the dialogue as: 


e The computer starts a new line and types out a sequence number 
when it wants input. 


e The user types in a line of data and signals the end of input 


with the ASCII ETX, which leaves the TTY carriage at the end 
of the input line. 


@e The computer, on recognizing the end character (ETX), writes 
out a CR sequence to signal that the computer is still there 
and running, and that input was received. Any delay between 
the CR and the next sequence number is due to computation time 
within the computer. 
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SVC15 PARAMETER BLOCK DCW CHAIN 


Lu | CC WRITE WRITE BUFF 


ADDR (DCW CHAIN) 
BUFFER 1 


SEQ NO. 2 | SEQNO. 3 


ADDR (BUFFER 1 BEGIN) 


ADDR (BUFFER 1 END) 
ADDR (BUFFER 2) 


* = UNDEFINED 


Figure 8-6 Example of an SVC15 Parameter Block and Associated 
Data 
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SVC15 PARAMETER BLOCK DCW CHAIN 


0 2 ADDR (OCW CHAIN) 


8 0 0 4 


LENGTH OF 
LAST WRITE 


NUMBER BYTES STORED 
IN BUFFER 


ADDR (BUFFER 1 BEG) 
ADOR (BUFFER 1 END) 
ADDR (BUFFER 2) 


BUFFER 1 


[seano ? [seono « 
Pscanoef 70 _| 


BUFFER 2 


DATA READ IN 


Figure 8-7 Parameter Block and Associated Fields 
After SVC15 Termination 


If the interpreter needs to store the input line image, along 
with its sequence number on a disk or tape, the program with 
sequence numbers can be listed when requested. For example: 


® Assume buffer 1 is a direct buffer of 72 characters’) and 
buffers 2 and 3 are direct buffers that are subsets of buffer 
1 

e Buffer 2 begins where buffer 1 begins 


e Buffer 2 ends where buffer 1 began +7; i.e., buffer 2 is just 
the first eight characters of buffer 1 


e Buffer 3 begins where buffer 1 began +8 
e Buffer 3 ends where buffer 1 ends. 
e Assume, as in the previous example, that buffer 2 contains a 


CR, LF and SEQ number space. 


By performing a write from buffer 2 and a read into buffer 3, 
buffer 1 then contains the sequence numbers and the input. These 
can then be written to a disk or magnetic tape by simply starting 
past the CR-LF sequence. See Figure 8-8. 
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Although considerably more complex, the program performs no 
additional work other than initially setting up the block. The 
commands (DCWs) specify time-out, which is normally an error 
time-out used to abort the call should the command not go to 
completion (possibly due to hardware problems) within the 
allotted time. Store a null. in the first position of a read 


buffer to determine if the read timed-out before or during data 
input . 


077-21 SVC15 PARAMETER BLOCK OCW CHAIN 
00 0 0 WRITE BUFFER, TIME-OUT, CHAIN DCW 
ADDR (DCW CHAIN) READ BUFFER, TIME-OUT, CHAIN DCW 
0002 oc WRITE 2, TIME-OUT 
ADDR (BUFF 2) 


ADDR (END BUFF 2} BUFFER 2 & BUFFER 3 


00] 


ADDR (BUFF 3) 
ADDR (END BUFF 3) 
ADDR (BUFF 4) 


SEQ NO. 2 


Figure 8-8 SVC15 Parameter Block After Termination 
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CHAPTER 9 
GENERATING AN OPERATING SYSTEM 
WITH DATA COMMUNICATIONS DEVICES 


9.1 INTRODUCTION 


An operating system configured with data communications devices 
is generated using the System Generation/32 (Sysgen/32) program. 


Sysgen/32 enables you to create and tailor an operating system to 


accommodate particular system requirements. Hardware and 
software features are selected and defined through sysgen 
configuration statements. These statements form a sysgen 


configuration input file. Driver and system modules provided in 
the OS/32 package are selected by Sysgen/32 based on the 
requirements indicated in these sysgen statements. 


You can create a new configuration input file or modify an 
existing one through Sysgen/32 commands. Once a configuration 
input file is created, it is processed by the Sysgen/32 program 
to produce macro calls. These macros are subsequently expanded, 
assembled and linked to yield the operating system. See the 
System Generation/32 (Sysgen/32) Reference Manual for a 
description of sysgen commands. 


9.2 DATA COMMUNICATIONS CONFIGURATION STATEMENT 


The sysgen ITAM configuration statement is used to configure data 
communications support in the operating system. Communications 
support consists of system modules, drivers and device control 
blocks (DCBs) and channel control blocks (CCBs), etc. The 
Grivers are stored in either the commmunications driver library 
or extended communications driver library. The system modules 
are stored in the system communications library. 


Every communications device to be configured in the operating 
system must be defined by a device descriptor statement. The 
sysgen DEVICES...END statements are used to delimit the device 
descriptor statements. Each communications device descriptor 
statement requires three parameters; the device name, the device 
address and the device code. The three required parameters must 
be entered in the order described. There are optional parameters 
describing other device details that can be entered in any order. 
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Example: 


In the following example, an asynchronous communications line is 
to be configured in the operating system. The first required 


parameter is the device name. The second parameter is the 
required device address, in this example, 40. The third required 
parameter, XD=X0830, is the device code. Note that 


communications device code specifications are preceded by XD 
specifying additional device configuration information. This is 
called the extended device code. 


LINE: , 40,144, XD=X0830, REA=XE1C9,WRI=XE809, PAD=2 


9.3 SYSTEM LIBRARIES 


Sysgen for OS/32 configured with the basic data communications 
subsystem is performed in the same manner as any other 
configuration of OS/32. However, the OS/32 Library Loader must 
first be used to merge the 0S/32 System Object Module Library 
with the Data Communications System Object Module Library and the 
OS/32 General-Purpose Driver Library with the Data Communications 
Driver/Terminal Manager Library. Sysgen/32 is used to process 
the resulting combined driver library. The OS/32 Library Loader 
is then used to generate the final load module as described in 
the System Generation/32 (Sysgen/32) Reference Manual. 


9.3.1 The Driver Library 


The recommended sysgen procedure requires that the driver library 
processed by Sysgen/32, and the system module library processed 
by the 0OS/32 library loader, each reside on a single disk file, 
magnetic tape or cassette. These libraries must, for an 08/32 
system with basic data communications, include object modules 
from the OS/32 software package and the basic data communications 
software package. The procedure for creating the combined 
libraries involves the use of the OS/32 Library Loader facilities 
for library manipulation. The reader should be familiar with the 
material contained in the OS/32 Library Loader Reference Manual. 


The only restriction on the order of modules in the driver 
library is that the DCB for each device code precedes the driver 
for that device. Since all Perkin-Elmer supplied libraries are 
in this order, the Basic Data Communications Driver/Terminal 
Manager Library can simply be appended to the existing general 
purpose driver library by a single DUPE operation. 


The combined system library situation is a bit more complex; the 
required order is that all EXEC object modules precede the data 
communications module and UBOT be last. Thus, it is necessary to 
create the combined system library on a third file or tape by 
Guplicating the 0S/32 System Module Library to the combined 
system library, duplicating the Data Communications System Module 
Library, and finally, copying UBOT from the 0S/32 System Module 
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Library. These procedures are described in detail in the Data 
Communications Packaging Information Document. 


9.3.2 Including User-Written Drivers 


To include a nonstandard device in the operating system, it must 
be defined in the sysgen device statements. The library 
containing the user-written driver (USERDLIB.LIB) for the device 
must be specified during the link phase of the Sysgen/32 process. 


Use reserved device codes 240-254 to configure a _ user-written 
driver in the system. 


Each device configured in the system gets an appropriate DCBxxx 
macro call written to the .MAC output file where xxx is the 


device code (e.g., DCB39, DCB147, DCB245, etc.). The DCBxxx 
macro creates the device DCB and external references to the 
Gevice driver (in DRIVER.LIB or USERDLIB.LIB). The user must 


create the DCBxxx macro definition and put it in the user 
USERDLIB.MLB file. 


9.3.2.1 Creating the DCBxxx Macro 


Creating the DCBxxx macro entails these six intermediate steps: 


L. Use MLU32 to get the DCBFORM macro from the SYSGEN32.MLB file 
to use as the pattern. 


2. Make the appropriate changes noted in DCBFORM to create the 
DCB macro. 


3. Save the file as DCBxxx.MAC. 


4. Use the MILU32 (Macro Library) Utility to add the DCBxxx macro 
definition to your USERDLIB.MLB file. This library will be 
searched by MACRO32 before the SYSGEN32.MLB in the normal 
sysgen process. Use care when creating definitions of macros 
with names identical to macro names in other libraries. 


5. Use Copy/32 or the LIBLDR Utility to add the driver code to 
your USERDLIB.LIB file. The USERDLIB.LIB file will be edited 
by 0S/32 Link before the standard DRIVER.LIB file. 
Therefore, modified Perkin-Elmer drivers that use _ standard 
Perkin-Elmer device codes can also be placed in USERDLIB.LIB, 
thereby preempting the standard Perkin-Elmer driver. 


6. Perform a sysgen using the _ standard SYSGEN.CSS. The 
USERDLIB.MLB file will be assigned and the DCBxxx definition 
will be used. 


See the DCBFORM macro in the SYSGEN32.MLB file. 


48-077 FOO ROO 9-3 


APPENDIX A 
LINE DRIVER COMMAND SUMMARY 


MODIFIER/ NUMBER 
COMMAND DATA DATA FIELD 

MODE COMMAND BYTE HEX VALID COMMAND BITS SPECIFIES 
NUL eee ee RRR te SS emer cpio Sie aed he 

NOP Xx00 }CC{CT} X} X}XXXxX}00000;000} Any valid 

SSeS Ses sare Sane aS = address 

WAIT Xx08 1CC;CT} X} O{XXXxX}00001;000} Halfword 

XFER Xx10 ;CC{CT} Xj} X{XXXxX}00010;000} Halfword 

CXFER XX18 }CCiCT; Xj} X{XXXxX}00011;000} 2 halfwords 

PR sae Ne a et tae teary eg Fe valid address 

CONTROL 0 wen enn n nee ----------- 

EXAMINE Xx0l 1CC{CT} X}TO{XXXx{;00000;001} Byte 

RING WAIT Xx09 1CC}CT; X}TO}XXXX;00001;001} None 

ANSWER XX1l }CC{CT} X}TO}XXXxX{00010/001} None 

DISCONNECT XxX19 ;CCiCT{ X}|TO{XXXxX};00011;001} None 
BREAD, Bt Ot See eee eee eee 

READ BUFFER XX02 }CC}CT;{BT {TO} XXXxX | 00000;010} Buffer 

READ1 XXOA ;CC{CT BT} TO{XXXxX;00001;010} Byte 

READ2 XX12 {CC{CT{ BT; TO} XXXX|00010{010} Byte 
PREPARE: =. 5. ws * gE eS eee eee 

PREP XX03 }CC{}CT; X}TO;XXxXxX;00000;011} Byte 
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MODE 


WRITE 


HOLD 


COMMAND 


WRITE BUFFER 


WRITE1 


WRITE2 


BREAK 


TOUT 


CMD2 


RCMD 


WCMD 


RDIS 


“WDIS 


DISK 
sYcT 


TRNSL 


SPEC CHAR 


_ TRECS 


MODIFIER/ 
COMMAND 
BYTE HEX 


XX04 


XXOC 


XX14 


XX05 


XX06 


XXOE 


XX16 


XX1E 


XX26 


XX2E 


XX36 


XX3E 


XX46 


XX4E 


XX56 


VALID COMMAND BITS 


eee es i a ae ee ee ee ee eee ee 
ee ee ee ee ae a ae ee 
ee i a a ee ee 


Default values are assembled in the DCB. 


NUMBER 
DATA DATA FIELD 
FIELDS SPECIFIES 


1.2 Buffer 


1 Byte 
2 Byte 
1 Halfword 
1 Fullword 
1 Byte 
1 Byte 
1 Byte 
1 Byte 
1. Byte 
1 Byte 
J Byte 
1 Byte 
1 Fullword 
Ll Halfword 
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APPENDIX B 
INTERFACE SIGNAL DEFINITIONS 


The following signals, defined by EIA Standard RS-232C, are used 
by the 103 and 201 series modems and are supported by the basic 
data communications subsystem. 


SIGNAL (RS-232C PIN COMMENTS 

DES IGNATION) 

Transmit data (BA) 2 Serial data sent from adapter 
to modem. 

Received data (BB) 3 Serial data received by 


adapter from modem. 


Request to send (CA) 4 Set by adapter when user 
program wishes to transmit. 


Clear to send (CB) 5 Set by modem when transmission 
can commence. 


Data set ready (CC) 6 Set by modem when it is 
powered on and ready to 
transfer data in response to 
data terminal ready (CD). 


Carrier detect (CF) 8 Set by modem when signal 
present. 
Data terminal ready (CD) 20 Set by adapter to enable modem 


to answer an incoming call on 
a switched line. Reset by 
adapter to disconnect call. 


Ring indicator (CE) 22 Set by modem when telephone 
rings. 
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A 
Access, device-dependent 


access, line driver 
Access, device-independent 


LCB 
nonbuffered access 
operation 
Access, line driver 
sequence of operations 
Access, terminal manager 
buffered access 
Adapters 
asynchronous 
bisynchronous adapters 
EDLC 
parallel 
serial 
ZBID adapters 
Add to task queue 
Allocate 
function 
routine 
ALLOCATE command 
American standard code for 
information interchange. 
See ASCII. 
ANSWER command 
ASCII 
Assign 
function 
routine 
ASSIGN command 
Asynchronous adapters 
MPC 
MUX, 2-line 
MUX, 8-line 
PASLA 
Asynchronous mode 


Baudot code 
Bisynchronous adapter 
QSA 
SELCH 
SSA 
synchronous 201 data set 
Buffer control 
Buffer types S5VC15 
chained buffers 
chained/queued buffer 
link word flag byte 
direct buffers 
indirect buffers 
queued buffers 
Buffered terminal manager 
input 
output 
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INDEX 


2-10 
5-1 
5-1 
2=5 
4-1 
4-2 
4-1 
4-2 
Sah 
5=2 
4-] 
4-2 
2-2 
223 
272 
2-2 
2-4 
6-71 
3=6 
6-72 
3-11 
5-26 
1-8 
3-6 
6-73 
3-13 
2-2 
2-3 
2=3 
2-3 
2-3 
1-6 


td 


Aunty N Nb e 
| 
rPrrwWOh PhP © 


mee mee wee ee ewe we wee wwe ew ew ew wm eee ewe me ee re ee ee ee ee eee es ee ee ee ee ee ee ee ee ew ee ee ee ew we we ew we we ww Oe oe ww ww ww ow ow ww wee ww ww ewe we we oe 


Cc 
CA/CD 
Cancellation 1/0 
CCB 


device-dependent portion 
device- independent 
portion 
Change access privileges 
Change access privileges 
function 
Channel control block. See 
CCB. 
Checkpoint 
function 
routine 
Close 
function 
routine 
CLOSE command 
CMEXIT subroutine 
CMTERM subroutine 


Collision avoidance/collision 


detection 
Command 
fetch 
modifier routines 
number field SVC15 
table 
Command functions 
allocate 
assign 
change access privileges 
checkpoint 
close 
delete 
fetch attributes 
rename 
reprotect 
VFC 
Communications methods 
CA/CD 
polling 
selection 
Conditional transfer 
command. See CXFER command 
Control block formats 
DCB data communications 
related portion 
device-dependent portion 
device-independent 
portion 
Control-type commands 
ANSWER 
DISCONNECT 
EXAMINE 
READ BUFFER 
read-type commands 
READ1 


© un 0 

1tdtoo f bdobtobtud [ 'orit 
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Control-type commands 
(Cont inuea ) 
READ2 
RING WAIT 

CSMA/DC 

CXFER command 


DASY driver 
DAT for asynchronous 
multidrop communications 
Data block descriptor, LCB 
Data codes 
ASCII 
Baudot 
EBCDIC 
Data communications 
analog 
distributed processing 
networks 
networks 
subsystem 
Data communications 
subroutines 
ITSRABS 
Data fields SVC15 
Data set link control 
transmission modes. 
See SDLC transmission modes. 
Data transmission modes. 
See modes, data transmission 
DCB data communications 
DCB data communications 
related portion 
DCB line driver use 
DCB pointers 
DCB .AOC 
DCB.DOCR 
DCB . DOCW 
DCB.INIT 
DCB.ITV 
DCB .MOCR 
DCB . MOCW 
DCB .OTV 
DCB .RDN 
DCB . TERM 
DCB .WDN 
DCB/LCB references 
DCSY driver 
DCT for asynchronous 
multidrop communications 
DCT for ZDLC communications 
DCW 
DCW pointer SVC15 
DDT for 3270 Emulator 
DDT for ZDLC communications 
Delete 
function 
routine 
DELETE command 
DETH driver 
Device control block. See 
DCB data communications. 
Device definition table. 
See DDT. 
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Device-dependent portion 
CCB 
DCB 
Device-dependent portion LCB 
Device-independent portion 
CCB 
DCB 
LCB 
Device mnemonic field 
DISCONNECT command 
Distributed processing 
networks 
Driver command work. 
DCW. 
Driver initiation routine 
Driver library 
DCBxxx macro creation 
user-written drivers 
Driver-termination phase 
Drop access table. See DAT. 
Drop control table. 
Drop definition table. 
DDT. 
DZBD driver 


See 


See 


EBCDIC 
EDLC 
Error handling 

CRC 

LRC 

VRC 
Error status field 
ESR 
Ethernet data link 
controller. See EDLC. 
Ethernet network 
Event service routine. 
ESR. 
EXAMINE command 
Extended binary coded 
decimal interchange code. 
See EBCDIC. 
Extension field 
EXTRN/ENTRY references 

BEBC.ASC 

CLOSMBSC 

CPT.RJE 

III 

INI TMBSC/FUNCMBSC 

IODONE / L[ODONE 2 

ISPTAB 

ISSEXEC 

IT.HALT 

JOURNAL 

TMREMW 

TOCHOFF 

TOCHON 

TWT .RJE 

WAIT 


See 
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See DCT. 
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F,G 


Fetch attributes 
function 

File manager handler. 

FMH. 

File size field 

Filename field 

FMH 

Format control 

Full-duplex mode 

Function code field 

Functions, terminal manager 
BLOCK A 
BLOCK AA 
BLOCK AB 
BLOCK AC 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
BLOCK 
buffer control 
format control 
special functions 
time-out control 


See 


NKEKMECQCCHNDAOVOZROAKAGH TOBWNaHAOQND 


H 


Half-duplex terminal 
Hard-wired modems 
Hold space (line break) 
command 
Hold-type commands 
hold space (line break) 


I,J,K 
ICMDINT subroutine 
Input/output block. See IOB. 
Input/output handler. See 


ITOH. 
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Interrupt service routine. 
See ISR. 

1OB for asynchronous 
multidrop communications 
IOH 

ISR 

ISSEXEC subroutine 

IT. .STOP subroutine 
ITGETBUF subroutine 
ITGETDAT subroutine 
ITGETMOD subroutine 
ITGETMOD2 subroutine 
ITIMLINK subroutine 
ITIMUNLK subroutine 
ITISPOTC subroutine 
ITISSTOP subroutine 
ITISTOTC subroutine 
ITSABS subroutine 


-ITSETREA subroutine 


ITXFRISR subroutine 


LAN 
LCB 


Gata block descriptor 
portion 
device-dependent portion 
device- independent 
portion 
Leased lines 
Length of last read field 
SVvc15 
Length of last write field 
Svc15 
Line control block. 


Line driver 
Gata communications 
example 

Line driver command types 

svcl15s 
control-type 
CXFER 
hold-type 
mode-type 
NOP 
null-type 
prepare-type 
test-type 
WAIT command 
write-type 
XFER 

Line drivers 
buffer management 
chained buffers 
command fetch 
command table 
command/modifier routines 
DASY 
DCB line driver use 
DCSY 
DETH 
driver-termination phase 


See LCB. 
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Line drivers (Continued) 
DZBD 
ISR 
line driver device 
interface 
modifier fetch 
modifying 
RAW turnaround 
special character 
routines 
structure 
use 
Lines 
multidrop 
point-to-point 


Local area network. See LAN. 


Logical record length field 
Logical unit. See lu. 
lu field 


M oO 
MASY nonbuffered terminal Operation, sequence of 4-2 
manager 2-8 Operator commands 3-10 
MBSC buffered terminal ALLOCATE 3-11 
manager 2-8 ASSIGN 3-13 
MMSM nonbuffered terminal CLOSE 3-15 
manager 2-8 DELETE 3-16 
MODE CMD2 (adapter) command 5-29 XALLOCATE 3-17 
MODE DISC command 5-30 XDELETE 3-19 
MODE RCMD and MODE WCMD 
commands 5-30 
MODE RDIS and MODE WDIS P 
commands 5-30 
MODE SPCHAR command 5-30 Parameter block 3-1 
MODE SYNCNT command 5-30 4-4 
MODE TOUT (time-out command functions 3-6 
interval) command 5-29 device mnemonic field 3-5 
MODE TRANSL command 5-30 error status field 3-3 
Mode-type commands extension field 3-5 
MODE CMD2 (adapter) 5-29 file size field 3-6 
MODE DISC 5-30 filename field 3-5 
MODE RCMD and MODE WCMD 5-30 function code field 3-3 
MODE RDIS and MODE WDIS 5-30 logical record length 
MODE SPCHAR 5-30 field 3-5 
MODE SYNCNT 5-30 lu field 3-5 
MODE TOUT (time-out read and write key fields 3-5 
interval) 5-29 Parameter block SVC15. See 
MODE TRANSL 5-30 SVC15 parameter bloc 
Modems Parity 


hard-wired modems 
voice grade 


Multiperipheral controller. 
See MPC. 

Multiplexors 
See MUXs. 

MUXs 


Networks 
data communications 
Ethernet 
LAN 
PENnet 
No operation command. See 
NOP command. 
Nonbuffered terminal manager 
NOP command 
Null-type commands 


PENnet network 
Point-to-point line 


mw wee ee ee we we wwe ew ww we ee we we ww ww we ew we mw we wm we ww ww ww ee mee ree ee ee ee ee ee ee ee ew ee ew ee we ee ee we ee ee ee wee ee we en ee ew we we we wee re ee ee we ee ee ww we we 


wideband = Polling process - 
Modes, data transmission PPSM nonbuffered terminal 
asynchronous mode 1-6 manager 2-8 
synchronous mode 1-7 PREPARE command 5-27 
ZBID 2-4 Prepare-type commands 5-27 
Modes, terminal PREPARE 5-27 
communications 1-4 PREPARE3 5-27 
full-duplex mode LS PREPARE3 command s=27 
half-duplex terminal L=5 Processing, SVCl 6-70 
simplex terminal uses 1-5 Processing, SVC7 
Modifier fetch 8-8 allocate 6-72 
MPC 2-3 assign 6-73 
Mulitidrop line LZ change access privileges 6-74 
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Processing, SVC7 (Continued) 
checkpoint 
close 
delete 
fetch attributes 
rename 
reprotect 
Protocols 
communications 
data link control 
error handling 


Q 


QSA 
Quad synchronous adapter. 
See QSA. 


RAW 


turnaround 
Read after write. See RAW. 
Read and write key fields 
READ BUFFER command 
Read-type commands 
READ] command 
READ2 command 
Register conventions 
Rename 

function 

routine 
Reprotect 

function 

routine 
RING WAIT command 


s 


SDLC transmission modes 
SDT for 3270 emulators 
SELCH 
Selection mechanism 
Selector channel. 
Simplex terminal uses 
Single-synchronous adapter. 
See SSA. 
Special character routines 
Speeds, terminal 
SSA 
Station description table. 
See SDT. 
Structure 
buffered terminal 
manager (input) 
buffered terminal 
manager (output) 
data communications 
line driver initiation 
routine 
line driver translation 
tables 
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See SELCH. 


Subroutine, data 
communications 

ITISPOTC 

Subroutines 
CMEXIT 
CMTERM 
data communications 
ICMDINT 
ISSEXEC 
IT. .STOP 
ITGETBUF 
ITGETDAT 
ITGETMOD 
ITGETMOD2 
ITIMLINK 
IT IMUNLK 
ITISSTOP 
ITISTOTC 
ITSETREA 
ITSRABS 
ITXFRISR 
SVC15 

Subsystem, data 

communications 


Supervisor call 1. See SVCl. 
Supervisor call 15. See 
SVC15. 
Supervisor call 7. See SVC7. 
Svcl 
data transfer function 
code 


format and coding 
parameter block 

SVCl extended options field 
connect 
disconnect 
echoplex 
format/image bit 

SVCl parameter block 
buffer end address 
buffer start address 
device-dependent status 
device-independent status 
extended options 
extended options field 
function code 
length of data transfer 
lu 
random address 

Svci5 

SVC15 function code field 

SVvC15 lu field 

SVC15 parameter block 
command number field 
Gata fields 
DCW pointe 
length of last read field 
length of last write 
field 
SVC15 function code field 
Svc15 lu field 
SVC15 status information 
field 

Svc15 status information 

field 
SVC15 structure and flow 
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SvC15 trap handling Timer management 6-71 


i 
buffer transfer trap 5-4 { Transfer in command. See 
command execution trap 5-4 1 XFER command. 
halt I/O termination trap 5-4 | Translation tables 8-6 
termination trap 5-4 i Transmission lines 
SVC7 H leased 1-10 
parameter block 3-1 H switched 1-10 
Switched lines 1-10 {| Trap handling SVC15. See 
Synchronous mode 1-7 i SVC15 trap handling. 
Sysgen, data communications 9-1 i 
driver library 9-2 H 
system libraries 9-2 i V 
Sysgen conventions ' 
DCB/LCB references 7-14 | Vertical forms control. See 
EXTRN/ENTRY references 7-14 =| VFC function. 
register 7-13 {| \VFC function 3-9 
System } Voice grade 1-9 
data communications ' 
terminals i=3 i 
initialization 6-71 |} W 
libraries 9-2 ! 
System, data communications 1-3 | WAIT command 5-24 
System generation. See | Wideband modems 1-9 
Sysgen. | WRITE BUFFER command 5-28 
| Write-type commands 5-27 
i WRITE BUFFER 5-28 
T,U H WRITE1 5-28 
i WRITE2 command 5-28 
Terminal communications } WRITE] command 5-28 
modes. See modes, terminal | WRITE2 command 5-28 
communications. i 
Terminal manager modification 7-1 H 
nonbuffered terminal : X,Y 
manager 7-2 i 
structure 7-2 | XALLOCATE command 3-17 
Terminal managers 2-6 { XDELETE command 3-19 
MASY 2-8 | XFER command 5-24 
MBSC 2-8 H 
MMSM 2-8 
PPSM 2-8 ! Z 
Terminal speeds. See i 
speeds, terminal {| ZBID adapters 2-4 
Terminals 1-4 i Zero-bit insertion/deletion 
Test-type commands 5-30). J adapters. See ZBID. 
Time-out control Poker u 2 
t 
| 
i 
i 
i 
iy 
' 
i 
i 
' 
H 
i 
i 
i 
1 
i 
' 
' 
i 
' 
i 
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